Purchase path determination method and device for enterprise shopping mall

Abstract

The invention provides a purchase path determination method and device for an enterprise shopping mall, and relates to the field of data processing, and the method comprises the steps: determining a compliance constraint condition set based on a determined purchase rule knowledge graph and purchase request information; when it is detected that the operation of the current user for the specific commodity touches a violation condition in the compliance constraint condition set, determining at least one alternative commodity scheme from compliance commodities by adopting a vector similarity algorithm; when a current user submits a purchase order, obtaining feature information of the purchase order, and determining a risk level of the purchase order based on a configured risk assessment model and a purchase rule knowledge graph; and generating a circulation path based on the risk level. Precise control of the purchase boundary is achieved through the purchase rule knowledge graph and the compliance constraint, compliance substitute commodities are recommended through the vector similarity algorithm, the approval path is dynamically generated in combination with risk assessment, and dynamic balance of compliance control and purchase efficiency is achieved.

Description

A method and apparatus for determining procurement paths for enterprise e-commerce platforms Technical Field

[0001] This application relates to the field of data processing, and more specifically, to a method and apparatus for determining procurement paths for enterprise e-commerce platforms. Background Technology

[0002] As large enterprises deepen their digital transformation, corporate procurement is gradually shifting from offline to online, with internal e-commerce marketplaces or connections to external e-commerce platforms becoming the mainstream procurement channels. Unlike personal online shopping, corporate procurement is subject to strict budget control, policy regulations, and audit requirements, and must meet multiple constraints such as supplier qualification verification, matching asset configuration standards, and multi-level approval processes.

[0003] Current electronic procurement systems still suffer from significant technical deficiencies: First, compliance verification is delayed; most systems only perform compliance verification after users submit their product selections and orders, directly rejecting orders for violations and wasting users' selection time. Second, catalog management is rudimentary, employing simple blacklist and whitelist mechanisms. Third, approval processes are rigid; fixed approval matrices apply to all procurement scenarios, resulting in extremely low efficiency in the procurement of low-value consumables and wasting resources on high-cost, labor-intensive approvals of low-value goods. Fourth, there is a lack of intelligent guidance mechanisms; when users violate procurement rules, the system simply enforces the rules without providing compliant alternatives, requiring users to consult the procurement department offline, increasing communication costs. Summary of the Invention

[0004] The purpose of this application is to provide a method and apparatus for determining the procurement path for enterprise e-commerce, which solves the above-mentioned problems existing in the prior art, optimizes user experience, and promotes the transformation of procurement management from experience-driven to data-driven.

[0005] Firstly, a method for determining procurement paths for enterprise e-commerce platforms is provided. This method may include: constructing a procurement rule knowledge graph based on acquired structured procurement data and entities extracted from unstructured policy documents; determining a set of compliance constraints based on the procurement rule knowledge graph and procurement request information provided by the current user; when it is detected that the current user's operation on a specific product violates the compliance constraints set, determining at least one alternative product from the compliant products corresponding to the procurement rule knowledge graph using a vector similarity algorithm; when the current user submits a purchase order, acquiring the feature information of the purchase order, and determining the risk level of the purchase order based on a configured risk assessment model and the procurement rule knowledge graph; generating a flow path based on the risk level, and driving the purchase order to flow along the flow path.

[0006] In one possible implementation, a set of compliance constraints is determined based on the procurement rule knowledge graph and the procurement request information, including: determining the authorized product categories and specifications corresponding to the user information from the procurement rule knowledge graph based on the user information in the procurement request information; obtaining the budget data of the cost center to which the user information belongs, and performing budget trial calculations based on the intent of the procurement request to determine the funding constraints.

[0007] In one possible implementation, when it is detected that the current user's operation on a specific product violates a violation condition in the set of compliance constraints, the following measures are taken: if an absolute prohibition rule is violated, the operation is forcibly blocked; if an exception is allowed, the user is provided with an exception application portal.

[0008] In one possible implementation, the structured procurement data includes at least organizational structure data, supplier agreement data, and budget item data.

[0009] In one possible implementation, the feature information of the purchase order includes multiple factors such as total order amount, product category sensitivity, supplier risk level, and user historical compliance credit score; the risk level of the purchase order is determined based on the configured risk assessment model and the purchase rule knowledge graph, including: quantifying multiple feature information into feature vectors; inputting the feature vectors into the risk assessment model for calculation to obtain a comprehensive risk score; and determining the risk level based on the comprehensive risk score.

[0010] In one possible implementation, the workflow path is defined as follows: the approval positions and departments within the enterprise are treated as nodes in a graph, the approval logic relationships are treated as edges in the graph, and the order risk level is used as a constraint to determine the shortest path from the starting node to the ending node that covers all necessary approval nodes.

[0011] In one possible implementation, after driving the purchase order to flow along the circulation path, the method further includes: collecting and analyzing the current user's behavior data and the compliance status of the purchase order in the entire procurement chain to obtain analysis results; and optimizing the rule parameters or relationships in the procurement rule knowledge graph based on the analysis results to obtain an optimized procurement rule knowledge graph.

[0012] Secondly, a procurement path determination device for enterprise e-commerce platforms is provided. This device may include: a construction unit for constructing a procurement rule knowledge graph based on acquired structured procurement data and entities extracted from unstructured policy documents; a determination unit for determining a set of compliance constraints based on the procurement rule knowledge graph and procurement request information provided by the current user; and, when it is detected that the current user's operation on a specific product violates a condition in the set of compliance constraints, using a vector similarity algorithm to determine at least one alternative product from the compliant products corresponding to the procurement rule knowledge graph; and, when the current user submits a purchase order, acquiring the feature information of the purchase order and determining the risk level of the purchase order based on a configured risk assessment model and the procurement rule knowledge graph; and a generation unit for generating a flow path based on the risk level and driving the purchase order to flow along the flow path.

[0013] Thirdly, an electronic device is provided, comprising a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other via the communication bus; the memory is used to store computer programs; and the processor, when executing the program stored in the memory, implements any of the steps described in the first aspect above.

[0014] Fourthly, a computer-readable storage medium is provided, wherein a computer program is stored therein, and when executed by a processor, the computer program implements the steps of any of the methods described in the first aspect above.

[0015] This application provides a procurement path determination method for enterprise e-commerce platforms. The method includes: constructing a procurement rule knowledge graph based on acquired structured procurement data and entities extracted from unstructured policy documents; determining a set of compliance constraints based on the procurement rule knowledge graph and procurement request information provided by the current user; when the current user's operation on a specific product triggers a violation in the compliance constraint set, using a vector similarity algorithm to determine at least one alternative product from the compliant products corresponding to the procurement rule knowledge graph; when the current user submits a purchase order, acquiring the purchase order's feature information and determining the purchase order's risk level based on a configured risk assessment model and the procurement rule knowledge graph; generating a flow path based on the risk level and driving the purchase order to flow along the flow path. This application achieves precise control of procurement boundaries through a procurement rule knowledge graph and compliance constraints, recommends compliant alternative products using a vector similarity algorithm, dynamically generates approval paths based on risk assessment, and promotes rule self-evolution through a closed-loop data system across the entire chain, ultimately achieving a dynamic balance between compliance control and procurement efficiency, and driving the transformation of procurement management from experience-driven to data-driven. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 is a flowchart illustrating a method for determining a procurement path for an enterprise e-commerce platform according to an embodiment of this application; Figure 2 is a structural diagram illustrating a device for determining a procurement path for an enterprise e-commerce platform according to an embodiment of this application; Figure 3 is a structural diagram illustrating an electronic device according to an embodiment of this application. Detailed Implementation

[0018] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0019] As large enterprises deepen their digital transformation, corporate procurement is gradually shifting from offline to online, with internal e-commerce marketplaces or connections to external e-commerce platforms becoming the mainstream procurement channels. Unlike personal online shopping, corporate procurement is subject to strict budget control, policy regulations, and audit requirements, and must meet multiple constraints such as supplier qualification verification, matching asset configuration standards, and multi-level approval processes.

[0020] Current electronic procurement systems still suffer from significant technical deficiencies: First, compliance verification is delayed; most systems only perform compliance verification after users submit their product selections and orders, directly rejecting orders for violations and wasting users' selection time. Second, catalog management is rudimentary, employing simple blacklist and whitelist mechanisms. Third, approval processes are rigid; fixed approval matrices apply to all procurement scenarios, resulting in extremely low efficiency in the procurement of low-value consumables and wasting resources on high-cost, labor-intensive approvals of low-value goods. Fourth, there is a lack of intelligent guidance mechanisms; when users violate procurement rules, the system simply enforces the rules without providing compliant alternatives, requiring users to consult the procurement department offline, increasing communication costs.

[0021] The preferred embodiments of this application are described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit this application. Furthermore, the embodiments and features in the embodiments of this application can be combined with each other without conflict.

[0022] Figure 1 is a flowchart illustrating a method for determining procurement paths for an enterprise e-commerce platform according to an embodiment of this application. As shown in Figure 1, the method may include: step S110, constructing a procurement rule knowledge graph based on the acquired structured procurement data and entities extracted from unstructured policy documents.

[0023] Structured procurement data includes at least organizational structure data, supplier agreement data, and budget item data.

[0024] Specifically, a centralized rules engine is built, which connects to multiple core systems within the enterprise through a standardized data access layer to obtain the structured procurement data required to build a procurement rules knowledge graph in a secure and compliant manner. These systems include: OA office system, ERP / FMS system, SRM system and PLM system.

[0025] Natural Language Processing (NLP) technology is used to extract entities and structure rules from unstructured enterprise procurement policy documents. The specific process involves: automatically identifying and extracting core entities related to the rules from the unstructured document, including but not limited to subject entities (job level, department, project team), scenario entities (city level, procurement scenario, road type), and constraint entities (category, unit price limit, procurement quota). Based on the extracted core entities, the semantic logic in the document is parsed to generate rule triples in the subject-scenario-constraint format. For example, parsing the text "Accommodation standard for business trips for directors and above is 1000 yuan / night in first-tier cities" yields the rule triples <subject: job level>=director+, <scenario: city level>=first-tier cities, <constraint: unit price><=1000>. Similarly, parsing the text "Annual printer procurement quota for the IT department is 5 units" yields the rule triples <subject: department=IT department>, <scenario: procurement category=printers>, <constraint: annual quota<=5 units>.

[0026] Based on ternary pairs and structured procurement data, a procurement rule knowledge graph containing node and edge attributes is constructed, as follows: The core node types of the procurement rule knowledge graph are determined, including employees, departments, projects, product categories (SKUCategory), suppliers, and budget items. Each node is associated with a corresponding unique identifier and basic attributes (e.g., product category nodes are labeled with category attributes, supplier nodes are labeled with qualification levels). Relationship attributes between nodes are defined to represent the compliance constraint logic of different dimensions of data, specifically including four core relationship attributes: allowed purchase, prohibited purchase, requires special approval, and quota limit. For example, the edge attribute between the IT department (department node) and the server (product category node) is allowed purchase; the edge attribute between the HR department (department node) and the server (product category node) is requires special approval; the edge attribute between ordinary employees (employee nodes) and laptops (product category nodes) is prohibited purchase; and the edge attribute between the finance department (department node) and the travel budget (budget item node) is a quota limit (annual 500,000 yuan).

[0027] The procurement rule knowledge graph constructed in this step integrates discrete procurement systems, budget data, organizational structures, and supplier agreements into an interconnected structured rule system. It supports reasoning for complex compliance logic (such as three-dimensional compliance judgment based on scenario, job level, and product category), and provides a unified rule query and matching basis for subsequent steps such as user context awareness and product compliance filtering, ensuring that all compliance verification actions are based on a consistent rule source.

[0028] Step S120: Based on the procurement rule knowledge graph and the procurement request information provided by the current user, determine the set of compliance constraints.

[0029] Specifically, based on the user information in the procurement request information, the authorized product categories and specifications corresponding to the user information are determined from the procurement rule knowledge graph; the budget data of the cost center to which the user information belongs is obtained, and a budget trial calculation is performed based on the intent of the procurement request to determine the funding constraints.

[0030] The above process can be understood as follows: First, extract core user information from the procurement request information, including but not limited to static attributes such as the user's department, job level, and associated project team, as well as dynamic attributes such as the procurement scenario (such as office supplies, marketing materials, and MRO industrial products), to form data linking user identity and procurement intent.

[0031] Using this user information as the query condition, the procurement rule knowledge graph is retrieved to match the node relationships corresponding to the user information. The user information also includes dynamic attributes: the currently selected project code and the delivery address. The procurement request information also specifies the procurement scenario (office supplies, marketing materials, MRO industrial products), which, combined with static attributes (ID, job level, department), forms a complete procurement context object.

[0032] Based on the relationships between employee, department, and product category nodes, the edge attributes (allowed purchase, prohibited purchase, special approval required) of the user's department and product category nodes are queried in the procurement rule knowledge graph to determine the scope of authorized product categories for that department (e.g., IT department and server category have an allowed purchase relationship, HR department and server category have a special approval required relationship). Combining the relationships between employee, job level, and product category nodes, product specifications that meet the user's job level configuration standards are filtered (e.g., ordinary employees and high-end laptop category have a prohibited purchase relationship, only able to access enterprise customized models; director-level employees and high-end office equipment category have an allowed purchase relationship). If the user is associated with a specific project team, the edge attributes of project and product category nodes are queried to add project-specific procurement authorization (e.g., Project A and specific experimental consumables category have an allowed purchase relationship), forming authorized product category and specification constraints in three dimensions: department, job level, and project.

[0033] Then, through the ERP / FMS system interface connected to the system, real-time budget data of the user's cost center is obtained, including core information such as the quarterly / annual remaining balance and the amount already used for the corresponding budget items; at the same time, Redis is used to cache frequently accessed budget data to ensure millisecond-level response speed in high-concurrency scenarios.

[0034] Based on the purchasing intent in the purchase request information (such as the estimated quantity and unit price range of the goods to be purchased), the system performs a budget pre-occupancy (Encumbrance) trial calculation, simulating the occupancy of the corresponding budget amount to determine whether the remaining funds of the current cost center are sufficient to cover potential purchasing needs. The budget pre-occupancy trial calculation is implemented through a distributed lock mechanism (Soft Lock) to address budget overrun issues in high-concurrency scenarios: when performing the budget pre-occupancy operation, the system applies a distributed lock to the corresponding budget amount of the user's cost center, ensuring that when multiple users simultaneously initiate purchase requests, the same budget amount can only be temporarily occupied by one user, avoiding the risk of overruns caused by overlapping budget occupancy. When a user cancels a purchase or the order times out, the distributed lock is automatically released, and the budget amount returns to an available state, ensuring the real-time accuracy of budget data. If the unit price of the goods to be purchased exceeds the remaining budget of the cost center, the condition of unit price ≤ remaining budget amount is directly used as one of the funding constraints.

[0035] In addition to monetary constraints, there are quota restrictions on the verification quantity, which are the quota limit edge attributes of cost center and product category nodes in the knowledge graph of retrieval procurement rules (e.g., a department's annual printer procurement quota is 5 units). If the procurement quota of the corresponding product category of the cost center has been exhausted, even if the budget is sufficient, a new financial constraint condition of procurement quantity ≤ remaining quota will be added.

[0036] The set of compliance constraints ultimately formed by the above steps includes two core constraints: first, the category constraints of authorized product categories and corresponding specifications; and second, the financial constraints of budget amount and procurement quota. These two constraints together constitute the core basis for subsequent product filtering and compliance judgment, ensuring that the constraints are strictly matched with the company's procurement policies, budget status, and user permissions.

[0037] In some embodiments, based on a set of compliance constraints, multi-dimensional dynamic filtering and recommendation sorting are performed on the mall's product library: products from qualified suppliers in the core list are prioritized for display, while products from temporary suppliers or blacklisted suppliers are blocked or downgraded; SKU attributes are matched according to user job level, and products that violate configuration standards are removed (e.g., when a regular employee searches for a mobile phone, the Pro version is filtered out). (High-end models such as Max); The user's original search request Q is rewritten as a compliant search request Q', and the filtering results satisfy the formula logic: Result=Search(Q)∩Filter(Policy)∩Filter(Supplier)∩Filter(Category); In the compliant product pool, products are sorted according to the principles of best price, fastest delivery, and highest agreement discount, combined with TCO (Total Cost of Ownership). In the intelligent recommendation sorting of the compliant product pool, compliance weight and agreement saving weight are introduced as core sorting factors: compliance weight is used to prioritize displaying products that are more compatible with the user's procurement scenario and job level configuration standards. The compatibility is calculated by the correlation matching degree between users and products in the procurement rule knowledge graph; agreement saving weight is used to prioritize displaying agreement products that can save procurement costs for enterprises. The weight value is positively correlated with the product agreement discount and the historical procurement cost saving amount; The final sorting result is calculated by weighting the best price, fastest delivery, highest agreement discount, lowest TCO with compliance weight and agreement saving weight, achieving dual optimization of compliance and enterprise cost saving goals. Products with preset preferential conditions such as long-term agreement discounts, low failure rates, and local warehouse delivery are marked with a "preferred" label and displayed to users first.

[0038] Step S130: When it is detected that the current user's operation on a specific product violates the compliance constraint set, at least one alternative product solution is determined from the compliant products corresponding to the procurement rule knowledge graph using a vector similarity algorithm.

[0039] Specifically, when it is detected that a user's operation on a specific product violates a set of compliance constraints, the following measures will be taken: if an absolute prohibition rule is violated, the operation will be forcibly blocked; if an exception can be applied for, the user will be provided with an exception application portal.

[0040] The above process may specifically include: monitoring the current user's actions on specific products (including searching, adding to cart, checkout, etc.), comparing the corresponding product attributes (category, specifications, supplier, estimated amount, etc.) with the established set of compliance constraints to determine whether a violation has occurred; if a violation has occurred, further distinguishing the violation rule type based on the edge attributes of product category, user, and constraint type in the procurement rule knowledge graph, and executing corresponding tiered blocking: if an absolute prohibition rule is triggered (i.e., the corresponding edge attribute in the procurement rule knowledge graph is "prohibited from purchasing" and there is no exception application permission), then a red light (Block) blocking is executed: directly prohibiting the user's current operation (such as prohibiting adding products to the shopping cart, blocking search results for prohibited products), and displaying a violation warning in a pop-up window, clearly informing the user of the company's procurement system clauses on which the violation is based (such as "you do not have hazardous chemical procurement qualifications, prohibiting the purchase of such chemical reagents"), and removing the entry point for further operation.

[0041] If an exception is triggered (i.e., the corresponding edge attribute in the procurement rule knowledge graph is "requires special approval" or the violation does not reach the absolute prohibition standard), a yellow light (Warning) interception will be implemented: the operation will not be directly prohibited, but a compliance warning will be displayed in a pop-up window, explaining the violation point (e.g., the unit price of the product exceeds the configuration standard for your job level by 10%), and an exception application entry will be provided, requiring the user to fill in the reason for the exception application (e.g., urgent project needs it urgently, compliant product is out of stock). After the user submits the application reason, the operation can continue, but the operation will be automatically marked and a higher-level approval process will be triggered later.

[0042] While performing the above-mentioned tiered interception, the alternative product solution generation process is initiated. Based on the vector similarity algorithm, suitable solutions are selected from the compliant product pool corresponding to the procurement rule knowledge graph. The specific process is as follows: based on the procurement rule knowledge graph, all products that meet the current user's compliance constraint conditions (i.e., the edge attribute is allowed to be purchased, and they meet the constraints of category, specifications, budget, etc.) are selected to form an exclusive compliant product pool.

[0043] Extract the core attributes of the non-compliant products from user operations (including product category, functional features, specifications, price range, application scenarios, etc.), and transform them into high-dimensional feature vectors using Embedding technology, which serve as the benchmark for similarity matching.

[0044] Calculate the cosine similarity between the feature vector of the non-compliant product and the feature vector of each product in the compliant product pool, and filter out products with similarity exceeding a preset threshold; if there are multiple products that meet the conditions, further sort them by combining indicators such as TCO (Total Cost of Ownership), agreement discount, and delivery time, and prioritize the product that is closest in function to the non-compliant product and has the best cost.

[0045] The sorted alternative product options (at least one) will be displayed simultaneously in the violation warning pop-up window, indicating the product name, specifications, supplier, agreed price, and core advantages. It will also clearly indicate that adopting the suggestion can save XX yuan and that the product is a compliant model recommended by the company, guiding users to select alternative products. Users can directly jump to the product details page by clicking on the alternative product to complete the compliant product selection.

[0046] For example, when a user attempts to purchase an Apple iPad (which has strong entertainment attributes and exceeds the configuration standards for ordinary employees), the system determines that it has violated the exception rules and implements a yellow light blocking action, popping up a window to indicate the basis for the violation and the entry point for the exception application. At the same time, based on the vector similarity algorithm, the system recommends a Microsoft Surface (which has office attributes and meets the configuration standards for ordinary employees), and marks it with a 92% functional matching degree and a negotiated price saving of 800 yuan, guiding the user to the compliant procurement path.

[0047] Step S140: When the current user submits a purchase order, obtain the characteristic information of the purchase order, and determine the risk level of the purchase order based on the configured risk assessment model and the purchase rule knowledge graph.

[0048] The characteristics of the purchase order include multiple factors such as total order amount, product category sensitivity, supplier risk level, and user's historical compliance credit score. Specifically, these multiple characteristics are quantified into feature vectors. The feature vectors are then input into a risk assessment model for calculation to obtain a comprehensive risk score. Based on the comprehensive risk score, the risk level is determined.

[0049] The above steps can be understood as follows: To achieve accurate calculation of the risk assessment model, all collected feature information is standardized and quantified, ultimately constructing a fixed-dimensional feature vector: quantification values ​​are divided according to the enterprise's preset amount range, for example: 0-1000 yuan is assigned a value of 1, 1000-5000 yuan is assigned a value of 3, 5000-20000 yuan is assigned a value of 5, and above 20000 yuan is assigned a value of 10, which quantifies the total order amount; product category sensitivity is quantified: low sensitivity is assigned a value of 1, medium sensitivity is assigned a value of 5, and high sensitivity is assigned a value of 10; supplier risk level is quantified: low risk... Assign a value of 1 for medium risk, 6 for high risk, and 10 for high risk; quantify the user's historical compliance credit score: directly use the original score (0-100 points) and normalize it according to the 100-point scale to the 10-point scale (e.g., 85 points are normalized to 8.5); quantify the supplementary features: assign a value of 8 for yes and 1 for no; arrange the above quantified feature values ​​in a fixed order according to the order total amount, product category sensitivity, supplier risk level, user's historical compliance credit score, whether the budget is exceeded, and whether it is a product outside the catalog, to form a multi-dimensional feature vector (e.g., [3,1,1,8.5,1,1]).

[0050] Next, the constructed feature vector is input into a preset risk assessment model, which calculates the comprehensive risk score of the order. A multi-factor weighted summation model with preset weights is used, and the weights of each feature dimension are set based on the priority of the enterprise's procurement policy (e.g., product category sensitivity weight 0.3, whether it exceeds the budget weight 0.25, total order amount weight 0.2, supplier risk level weight 0.15, user's historical compliance credit score weight 0.05, whether it is an off-catalog product weight 0.05). The weights can be dynamically adjusted through the rule priority edge attribute of the procurement rule knowledge graph. The quantified value of each dimension in the feature vector is multiplied by the corresponding weight, and all the product results are summed to obtain the comprehensive risk score (score range 0-100). Cross-validation is performed in conjunction with the procurement rule knowledge graph. If the order contains highly sensitive products and the supplier is of high risk level, even if the scores of other dimensions are low, the model will trigger a weighting coefficient correction to ensure that high-risk factors are not underestimated.

[0051] Finally, based on the calculated comprehensive risk score, risk levels are classified according to preset thresholds, as follows: If the comprehensive risk score is <20, it is determined to be low risk; the corresponding procurement scenarios are sufficient budget, contracted suppliers, low-sensitivity goods, and users with good compliance and credit (such as purchasing office supplies); if the comprehensive risk score is between 20 and 60, it is determined to be medium risk; the corresponding procurement scenarios are asset-type equipment procurement and cooperation with non-core warehouse suppliers (such as purchasing regular office computers); if the comprehensive risk score is >60, it is determined to be high risk; the corresponding procurement scenarios are exceeding the budget by more than 20%, high-sensitivity goods (such as hazardous chemicals), goods not listed in the catalog, and users with poor compliance and credit.

[0052] Through the above steps, the risk level of the order is finally output. This level directly determines the generation logic of the subsequent approval path, ensuring that the approval process is accurately matched with the order risk, neither ignoring high-risk risks nor wasting approval resources for low-risk procurements.

[0053] Step S150: Based on the risk level, generate a flow path and drive the purchase order to flow along the flow path.

[0054] The workflow path is defined by taking the approval positions and departments within the enterprise as nodes of the graph, the approval logic relationships as edges of the graph, and the order risk level as a constraint. The shortest path from the starting node to the ending node and covering all necessary approval nodes is determined in the graph.

[0055] Specifically, internal approval positions (such as direct supervisors, CFOs, and VPs) and functional departments (such as security, IT, EHS, and procurement) are defined as nodes in the graph. Each node is associated with a unique identifier and approval authority scope (e.g., the security department node only handles approvals related to hazardous chemicals and highly sensitive equipment). Approval logic relationships (e.g., approval by the direct supervisor must be submitted to the CFO for approval, and approvals from the security department and IT department can be executed in parallel) are defined as directed edges in the graph. Edge attributes indicate the approval flow direction and dependencies (sequential dependency / parallel independence). Based on the compliance constraints of the procurement rule knowledge graph, necessary approval nodes are marked for different risk types (e.g., orders exceeding the budget require the CFO node, hazardous chemical procurement orders require the security department node, and non-catalog commodity orders require the procurement expert node). Necessary nodes are the mandatory nodes for the corresponding type of order.

[0056] Next, based on the order's risk level and risk type (e.g., over-budget, hazardous chemicals, non-catalog goods), the constraints for path generation are defined to ensure accurate matching between the path and the risk: For low-risk levels, the constraint is that no manual approval nodes are required; only the order submission node, automatic approval node, and PO generation node are retained in the workflow, with the only necessary node being the automatic approval node (the system has built-in compliance verification logic); for medium-risk levels, the constraint is that only one level of manual approval is required, with the necessary node being the direct supervisor node, and the path must cover this node without any additional redundant approval nodes; for high-risk levels, the constraint is that all related necessary nodes must be covered, and the essential nodes are determined according to the risk type (e.g., over-budget orders must include the CFO node, hazardous chemical orders must include the safety department node, and non-catalog goods orders must include the procurement expert node), and the path must include all related necessary nodes with the fewest possible workflow steps.

[0057] The dynamic workflow engine is invoked, employing Dijkstra's algorithm to search for the shortest path that satisfies the constraints in the approval node graph. The specific calculation process is as follows: the starting node is the order submission node, and the ending node is the PO generation node (approved) or the order modification notification node (rejected). With the premise of covering all necessary nodes, and with the optimization objectives of minimizing the number of nodes in the path and the shortest workflow time, the optimal directed path from the starting node to the ending node is searched. Path generation results: low-risk orders use the shortest path from the order submission node, automatic approval node, and PO generation node, without any manual approval nodes; medium-risk orders use the shortest path from the order submission node, direct supervisor node, and PO generation node, requiring only one level of manual approval; high-risk orders combine necessary nodes according to risk type, generating the shortest path containing all necessary nodes (e.g., for hazardous chemicals and over-budget orders, the path is the order submission node, direct supervisor node, safety department node, CFO node, VP node, and PO generation node).

[0058] If a purchase order contains multiple goods (e.g., both office computers and chemical reagents), the system identifies the risk types and necessary approval nodes for different goods and executes the order splitting workflow logic: the original order is split into multiple sub-orders according to the product category (e.g., an office computer sub-order and a chemical reagent sub-order), and each sub-order is associated with a corresponding risk level and necessary approval node; an independent shortest workflow path is calculated for each sub-order (e.g., the office computer sub-order is a medium-risk path, and the chemical reagent sub-order is a high-risk path); the sub-order approval paths are executed in parallel, and after all sub-orders are approved, the system merges them into the original order to generate the final PO; if any sub-order is rejected, the system terminates the overall workflow and notifies the user to modify the corresponding goods.

[0059] After generating the workflow path, the system drives the order to flow along the path and synchronizes the workflow status in real time: Purchase order information and pending approval items are pushed to the user terminals (such as the office software or mobile APP of the direct supervisor) of each approval node in the order of the path, and the approval priority and necessary approval basis are marked; the approval results (pass / reject / pending approval) of each node are recorded in real time. If a node rejects the approval, the workflow is immediately terminated and the reason for rejection and modification suggestions are pushed to the user; if all nodes approve, the PO generation process is automatically triggered and the PO file is pushed to the corresponding supplier; after the order flows to the PO generation node, the system releases the pre-occupied budget (if the approval is rejected, the pre-occupied budget is released immediately; if the approval is passed, the pre-occupied budget is converted into actual use), ensuring that the budget data is accurate and up-to-date.

[0060] For example, when a user submits a mixed order containing both regular office supplies and hazardous chemical reagents, it is split into a low-risk office supplies sub-order and a high-risk hazardous chemical reagent sub-order: the office supplies sub-order generates an automatic approval and purchase order (PO) path without manual intervention; the hazardous chemical reagent sub-order generates a path through the direct supervisor, safety department, finance director, and PO, covering all necessary nodes; the two sub-orders are approved in parallel, and after both are approved, they are merged to generate the final PO, driving procurement execution.

[0061] In some embodiments, after driving the purchase order to flow along the circulation path, the method further includes: collecting and analyzing the current user's behavior data and the compliance status of the purchase order in the entire procurement chain to obtain analysis results; and optimizing the rule parameters or relationships in the procurement rule knowledge graph based on the analysis results to obtain an optimized procurement rule knowledge graph.

[0062] The above process can be understood as follows: Through a pre-set data tracking mechanism, comprehensive behavioral data and compliance status data are collected throughout the entire procurement process. All data is associated with nodes and edge attributes of the procurement rule knowledge graph. Specific data collection includes: recording user actions at each stage of the procurement process, including but not limited to records of failed product searches, click-through rates / selection rates / abandonment rates of recommended product lists, number of times violation warning pop-ups are ignored, number of exception applications submitted and reasons given (e.g., out-of-stock compliant products, urgent projects requiring urgent funding), and operation time at each approval node (e.g., time spent on supervisor approval, time spent on CFO approval); and recording the entire lifecycle of the procurement order. The compliance status of the cycle includes the interception results during the product addition stage (red light / yellow light / green light), the approval results after order submission (approved / rejected / forced submission), the consistency verification results of orders, invoices and receipts during the invoice settlement and reimbursement process (consistent / inconsistent), and supplier performance compliance records (such as whether goods are supplied at the agreed price and whether they are delivered on time). Simultaneously, the system collects inventory status data from the compliant product pool (such as information on frequently recommended but long-term out-of-stock products), supplier service quality data (such as historical cooperation violation records and performance rates), and user historical compliance credit score change data (such as records of credit score reduction due to product replacement violations).

[0063] Statistical analysis and logical reasoning were performed on the collected multi-dimensional data to obtain targeted analytical results: The reasons for the high frequency of exception requests were analyzed. If it was found that a certain type of compliant product was frequently submitted as an out-of-stock exception due to long-term stock shortages, it was determined that the association rules between that product category and the supplier were flawed. If a user at a certain job level repeatedly applied for exceptions to purchase high-end products due to excessively low configuration standards, it was determined that the quota restriction rules between that job level and the product category needed adjustment. The time distribution of each approval node was analyzed. If the average time of a certain non-essential approval node exceeded 30% of the total approval time, and no interception was found at that node, it was determined that... For orders with excessively high risk, the association rules between the node and the approval path can be optimized; the selection rate and out-of-stock rate of the compliant product pool are statistically analyzed. If the selection rate of a certain type of product is less than 10% and there are no out-of-stock records, it is determined that the matching degree between the product category and the user is insufficient, and there may be an outdated configuration issue; if the fulfillment rate of the core library supplier's products is less than 85%, it is determined that the risk level of the supplier node needs to be adjusted; the consistency data of orders, invoices and receipts are verified. If it is found that a user places an order for compliant products but actually replaces them with non-compliant products, it is determined that the compliance credit of the user node has defects and needs to be included in credit management.

[0064] The rule parameters, node attributes, and edge attributes of the procurement rule knowledge graph are updated, including: For analysis results such as excessively low job level configuration standards and unreasonable quota limits, the constraint parameters of the corresponding rule triples are automatically suggested for adjustment. For example, the configuration standard for ordinary employee office computers ≤ 5000 yuan is adjusted to ≤ 6000 yuan, and the quota limit edge attributes for ordinary employees (employee node) and office computers (product category node) in the knowledge graph are updated simultaneously; For analysis results such as out-of-stock compliant products and low supplier fulfillment rates, the relationships between nodes are optimized. For example, a supplier node with a high fulfillment rate is added, and a purchase permission edge attribute is established between this supplier and the corresponding product category; Low selection rate and low configuration... Outdated product category nodes will be removed, or their edge attributes with department nodes will be modified to prohibit purchases. For users with discrepancies between orders, invoices, and receipts, they will be added to a compliance and credit blacklist. The edge attributes of their nodes with all high-sensitivity product category nodes will be modified to require special approval or prohibit purchases, and their automatic approval privileges will be revoked. Their historical compliance and credit scores will also be updated. Optimization suggestions will be pushed to the procurement management backend. After confirmation by administrators, the relevant configurations of the procurement rule knowledge graph will be automatically updated. If optimization suggestions involve adjustments to the supplier database (such as introducing new suppliers), the system will simultaneously connect to the SRM system to add supplier nodes and label their attributes, ensuring that the optimized knowledge graph directly impacts subsequent procurement processes.

[0065] This application provides a procurement path determination method for enterprise e-commerce platforms. The method includes: constructing a procurement rule knowledge graph based on acquired structured procurement data and entities extracted from unstructured policy documents; determining a set of compliance constraints based on the procurement rule knowledge graph and procurement request information provided by the current user; when the current user's operation on a specific product triggers a violation in the compliance constraint set, using a vector similarity algorithm to determine at least one alternative product from the compliant products corresponding to the procurement rule knowledge graph; when the current user submits a purchase order, acquiring the purchase order's feature information and determining the purchase order's risk level based on a configured risk assessment model and the procurement rule knowledge graph; generating a flow path based on the risk level and driving the purchase order to flow along the flow path. This application achieves precise control of procurement boundaries through a procurement rule knowledge graph and compliance constraints, recommends compliant alternative products using a vector similarity algorithm, dynamically generates approval paths based on risk assessment, and promotes rule self-evolution through a closed-loop data system across the entire chain, ultimately achieving a dynamic balance between compliance control and procurement efficiency, and driving the transformation of procurement management from experience-driven to data-driven.

[0066] Corresponding to the above method, this application embodiment also provides a procurement path determination device for enterprise e-commerce, as shown in Figure 2. The device includes: a construction unit 210, used to construct a procurement rule knowledge graph based on the acquired structured procurement data and entities extracted from unstructured policy documents; a determination unit 220, used to determine a set of compliance constraints based on the procurement rule knowledge graph and the procurement request information provided by the current user; and, when it is detected that the current user's operation on a specific product triggers a violation condition in the set of compliance constraints, using a vector similarity algorithm to determine at least one alternative product solution from the compliant products corresponding to the procurement rule knowledge graph; and, when the current user submits a purchase order, obtaining the feature information of the purchase order and determining the risk level of the purchase order based on the configured risk assessment model and the procurement rule knowledge graph; and a generation unit 230, used to generate a flow path based on the risk level and drive the purchase order to flow along the flow path.

[0067] The functions of each unit in the procurement path determination device for an enterprise e-commerce platform provided in the above embodiments of this application can be implemented through the above-described method steps. Therefore, the specific working process and beneficial effects of each unit in the procurement path determination device for an enterprise e-commerce platform provided in the embodiments of this application will not be repeated here.

[0068] This application also provides an electronic device, as shown in FIG3, including a processor 310, a communication interface 320, a memory 330 and a communication bus 340, wherein the processor 310, the communication interface 320 and the memory 330 communicate with each other through the communication bus 340.

[0069] The memory 330 is used to store computer programs; the processor 310, when executing the program stored in the memory 330, performs the following steps: constructing a procurement rule knowledge graph based on the acquired structured procurement data and entities extracted from unstructured policy documents; determining a set of compliance constraints based on the procurement rule knowledge graph and the procurement request information provided by the current user; when it is detected that the current user's operation on a specific product violates the compliance constraints in the set of compliance constraints, using a vector similarity algorithm to determine at least one alternative product from the compliant products corresponding to the procurement rule knowledge graph; when the current user submits a purchase order, acquiring the feature information of the purchase order, and determining the risk level of the purchase order based on the configured risk assessment model and the procurement rule knowledge graph; generating a flow path based on the risk level, and driving the purchase order to flow along the flow path.

[0070] The communication bus mentioned above can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0071] The communication interface is used for communication between the aforementioned electronic devices and other devices.

[0072] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0073] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0074] Since the implementation methods and beneficial effects of the various devices in the above embodiments of the electronic device can be achieved by referring to the steps in the embodiment shown in Figure 1, the specific working process and beneficial effects of the electronic device provided in this application embodiment will not be repeated here.

[0075] In another embodiment provided in this application, a computer-readable storage medium is also provided, which stores instructions that, when executed on a computer, cause the computer to perform a procurement path determination method for an enterprise e-commerce platform as described in any of the above embodiments.

[0076] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute a procurement path determination method for an enterprise e-commerce platform as described in any of the above embodiments.

[0077] Those skilled in the art will understand that the embodiments in this application can be provided as methods, systems, or computer program products. Therefore, the embodiments in this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the embodiments in this application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0078] This application describes embodiments of methods, apparatus (systems), and computer program products according to embodiments of this application with reference to flowchart illustrations and / or block diagrams. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more blocks of the flowchart illustrations and / or one or more blocks of the block diagrams.

[0079] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0080] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0081] Unless otherwise defined, the technical or scientific terms used in this application shall have the ordinary meaning understood by one of ordinary skill in the art to which this invention pertains. The terms "first," "second," and similar terms used in this application do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed following the word and their equivalents, without excluding other elements or objects. Terms such as "connected," "coupled," or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are used only to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0082] Although preferred embodiments have been described in this application, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the embodiments in this application are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments in this application.

[0083] Obviously, those skilled in the art can make various modifications and variations to the embodiments of this application without departing from the spirit and scope of the embodiments of this application. Therefore, if these modifications and variations to the embodiments of this application fall within the scope of the embodiments of this application and their equivalents, then these modifications and variations are also intended to be included in the embodiments of this application.

Claims

1. A method for determining the procurement path for an enterprise e-commerce platform, characterized in that, The method includes: constructing a procurement rule knowledge graph based on acquired structured procurement data and entities extracted from unstructured policy documents; determining a set of compliance constraints based on the procurement rule knowledge graph and procurement request information provided by the current user; when it is detected that the current user's operation on a specific product violates a condition in the set of compliance constraints, using a vector similarity algorithm to determine at least one alternative product from the compliant products corresponding to the procurement rule knowledge graph; when the current user submits a purchase order, acquiring the feature information of the purchase order, and determining the risk level of the purchase order based on a configured risk assessment model and the procurement rule knowledge graph; generating a flow path based on the risk level, and driving the purchase order to flow along the flow path.

2. The method as described in claim 1, characterized in that, Based on the procurement rule knowledge graph and the procurement request information, a set of compliance constraints is determined, including: based on the user information in the procurement request information, determining the authorized product categories and specifications corresponding to the user information from the procurement rule knowledge graph; obtaining the budget data of the cost center to which the user information belongs, and performing budget calculations based on the intent of the procurement request to determine funding constraints.

3. The method as described in claim 1, characterized in that, When it is detected that the current user's operation on a specific product violates the set of compliance constraints, the following measures are taken: if an absolute prohibition rule is violated, the operation is forcibly blocked; if an exception is allowed, the user is provided with an exception application portal.

4. The method as described in claim 1, characterized in that, The structured procurement data includes at least organizational structure data, supplier agreement data, and budget item data.

5. The method as described in claim 1, characterized in that, The characteristic information of the purchase order includes multiple factors such as total order amount, product category sensitivity, supplier risk level, and user's historical compliance credit score. Based on the configured risk assessment model and the purchase rule knowledge graph, the risk level of the purchase order is determined, including: quantifying multiple characteristic information into feature vectors; inputting the feature vectors into the risk assessment model for calculation to obtain a comprehensive risk score; and determining the risk level based on the comprehensive risk score.

6. The method as described in claim 1, characterized in that, The workflow path is defined by treating the internal approval positions and departments of the enterprise as nodes in a graph, the approval logic relationships as edges in the graph, and the order risk level as a constraint condition, to determine the shortest path from the starting node to the ending node in the graph that covers all necessary approval nodes.

7. The method as described in claim 1, characterized in that, After driving the purchase order to flow along the circulation path, the method further includes: collecting and analyzing the current user's behavior data and the compliance status of the purchase order in the entire procurement chain to obtain analysis results; and optimizing the rule parameters or relationships in the procurement rule knowledge graph based on the analysis results to obtain an optimized procurement rule knowledge graph.

8. A procurement path determination device for an enterprise e-commerce platform, characterized in that, The apparatus includes: a construction unit for constructing a procurement rule knowledge graph based on acquired structured procurement data and entities extracted from unstructured policy documents; a determination unit for determining a set of compliance constraints based on the procurement rule knowledge graph and procurement request information provided by the current user; and, when it is detected that the current user's operation on a specific product violates a condition in the set of compliance constraints, determining at least one alternative product from the compliant products corresponding to the procurement rule knowledge graph using a vector similarity algorithm; and, when the current user submits a purchase order, acquiring the feature information of the purchase order and determining the risk level of the purchase order based on a configured risk assessment model and the procurement rule knowledge graph; and a generation unit for generating a flow path based on the risk level and driving the purchase order to flow along the flow path.

9. An electronic device, characterized in that, The electronic device includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; the memory is used to store computer programs; and the processor, when executing the program stored in the memory, implements the steps of the method described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method described in any one of claims 1-7.

Images