AI-driven conversational ERP order generation method and system

Abstract

The application relates to an AI-driven conversational ERP order generation method and system, and belongs to the field of resource planning systems. The method comprises the following steps: loading user permissions and collecting historical behavior sequences in response to a wake-up instruction; predicting an order intention and generating an active guidance prompt based on a time sequence coding model; extracting initial order elements by using a large language model, combining a static permission vector and a dynamic context vector for joint constraint optimization to generate accurate order elements; calling an ERP master data interface to obtain real business data after permission verification to generate a basic order data set; performing conflict resolution through a structured constraint rule library and a model output-rule bidirectional verification mechanism to generate a pre-order data object; and writing into a database to generate an official order after multi-modal fusion confirmation and risk control pre-checking. The application has the advantages that permission verification is pre-positioned, data is accurate and reliable, active guidance is provided, and multi-modal risk pre-checking is performed, so that order entry efficiency and compliance are significantly improved.

Description

Technical Field

[0001] This invention relates to an AI-driven conversational ERP order generation method, belonging to the field of resource planning systems. Background Technology

[0002] Enterprise Resource Planning (ERP) systems are the core of enterprise information management, and sales order entry is one of the most frequent operations for business personnel in their daily work. Traditional ERP order entry methods rely on graphical user interfaces, requiring users to switch between multiple menu pages, sequentially selecting customers, products, quantities, and price lists, resulting in a long and inefficient workflow. This is especially problematic in mobile scenarios where screen size is limited and menu layers are deep, leading to a poor user experience.

[0003] In recent years, some ERP vendors have attempted to introduce conversational interaction, allowing users to input order information via natural language, with the system using AI models to interpret the intent and automatically fill in the form. However, existing solutions still have many shortcomings in practical applications: the AI ​​dialogue module is disconnected from the ERP permission system, and permission verification is often postponed, rendering user input invalid; AI-generated business data such as prices and inventory are mostly estimates, lacking accuracy; the triggering method is limited, lacking contactless wake-up methods such as voice; and the ability to perceive the context of multi-turn dialogues is weak, resulting in low accuracy in parsing entity references such as "old customers" and "frequently used products."

[0004] Specifically, existing technologies suffer from the following main shortcomings: First, they lack the ability to parse complex order structures and handle conflicts. For orders with multiple products and multi-dimensional constraints, there is a lack of structured rule verification and conflict resolution mechanisms, which can easily lead to submission failures when issues such as product-quantity-price mismatches or inventory mismatches occur. Second, the confirmation process lacks multimodal fusion verification. Confirmation is based solely on a single interface click or voice command, making it susceptible to environmental interference and voice misrecognition. Furthermore, order risk control verification is postponed, failing to provide advance risk warnings during the confirmation process. Third, the interaction mode is passive, only able to respond passively to user input and unable to predict order intent based on historical user behavior data. This results in a high learning curve for new users and makes it difficult to further reduce order entry time. Summary of the Invention

[0005] To overcome the shortcomings of existing technologies, this invention provides an AI-driven conversational ERP order generation method and system. The technical solution of this invention is as follows: An AI-driven conversational ERP order generation method includes the following steps: Step S1: In response to the detected wake-up command, load the current user's ERP permission configuration information and synchronously collect the user's historical behavior sequence data; Step S2: Construct a behavior sequence vector based on the user's historical behavior sequence data, use a time-series coding model to predict the order intent and generate personalized dialogue guidance prompts, which are presented synchronously through interface bubbles and voice to complete the proactive dialogue initialization; if the user has no historical behavior sequence data, skip the proactive guidance step and directly enter the dialogue listening state, waiting for the user's natural language input. Step S3: Obtain the user's natural language input, and use a large language model combined with dialogue guidance prompts to extract initial order elements from the input text. The order elements include at least customer identifier, product identifier, and quantity. Step S4: Introduce a dynamic context awareness layer to maintain the joint constraints of the static permission vector and the dynamic context vector, and pre-match and optimize the initial order elements with the joint constraints to generate accurate order elements; Step S5: Compare and verify the precise order elements with the ERP permission configuration information in real time. The verification includes customer permission verification, product permission verification and regional permission verification. Step S6: If the verification passes, call the ERP master data interface to obtain the real business data associated with the order elements and generate the basic order dataset; Step S7: Based on the structured constraint rule base and the model output-rule bidirectional verification mechanism, perform multi-dimensional alignment verification and conflict resolution on the basic order dataset to generate compliant pre-order data objects; Step S8: Render the pre-order data object into a visual interactive confirmation interface, and broadcast the core order information through voice synthesis; Step S9: Analyze the user's true intent using multimodal signals from integrated voice commands, interface operations, and corrective inputs; simultaneously call the risk control rule engine to complete order pre-inspection; embed risk items into the confirmation interface for highlighting and key voice broadcasts; Step S10: In response to the user's final confirmation instruction, write the pre-order data object into the ERP database, generate a formal order and return the order number, and synchronously update the user's historical behavior sequence data; The method for constructing the behavior sequence vector in step S2 is as follows: The user's historical behavior sequence over the past T days is used as a reference. Input a temporal coding model Encoder, output a sequence vector of behaviors. The temporal coding model is a sequence coding network based on Transformer or BERT; in step S7, conflict resolution uses minimum edit distance to backtrack the user's original input, and the minimum edit distance... The calculation formula is: ; Where |a| and |b| represent the lengths of the input strings a and b, respectively. The function is an indicator; it takes the value 0 when two characters are the same, and 1 otherwise. In step S9, the multimodal fusion confirmation engine uses a large multimodal fusion model to synchronously collect voice commands. Interface operation and text input Semantic alignment and intent parsing are performed through an attention mechanism, and the fused feature representation is as follows: ,in This is a learnable weight matrix.

[0006] In step S1, the wake-up command includes a voice wake-up command and a graphical interface wake-up command. The voice wake-up command is triggered by a preset wake-up word, and the graphical interface wake-up command is triggered by a wake-up control in the user interface.

[0007] In step S1, the ERP permission configuration information includes the current user's visible customer list, salable product list, and jurisdiction list. In step S1, the permission configuration information is encapsulated into a static permission vector. , serving as the fundamental contextual constraints for large language models.

[0008] The user historical behavior sequence data collected in step S1 includes: the user's order operation trajectory in the past 7 days, high-frequency transaction customers, list of frequently sold products, current ERP interface stay context, historical order element preferences and peak order placement time data.

[0009] The dynamic context vector in step S4 This includes the user's recently viewed customer list, the customer or product page currently viewed on the ERP interface, confirmed order elements from the current conversation, historical high-frequency transaction entities, and a matching entity library based on user-defined expressions; the joint constraints serve as prefix system hints for the large language model, prioritizing matching entities in the dynamic context vector, and if no valid match is found, falling back to a full matching of the static permission vector; the pre-matching optimization process is represented as... ,in This is the initial order element vector. This is an entity analytic function based on joint constraints.

[0010] The real-time comparison and verification in step S5 specifically includes: The extracted customer identifiers are matched against the list of visible customers. If the match fails, the cosine similarity of the customer names is calculated, and a guiding question containing similar customer names is generated. The extracted product identifier is matched with the list of available products. If the match fails, a guiding question containing alternative products is generated. The system matches the region field in the customer's master data with the list of governed regions. If the match fails, an insufficient permissions message is generated.

[0011] In step S6, the real business data includes: precise prices obtained from the ERP price master data, real-time inventory levels obtained from the ERP inventory module, customer credit limits obtained from the ERP credit management module, and standard delivery cycles obtained from the ERP delivery management module; the process of generating the basic order dataset is as follows: refining order elements... Used as a query key to call the ERP master data interface function. Returns a multi-dimensional business data vector containing price, inventory, credit limit, and delivery time. .

[0012] In step S7, the structured constraint rule base includes: order line product code uniqueness rules, order quantity non-negative rules, sales price not lower than the agreed floor price rules, available inventory greater than or equal to the order quantity rules, total order amount not exceeding the customer's available credit limit rules, and delivery cycle compliance rules; the model output-rule bidirectional verification mechanism is as follows: first, the basic order dataset is input into the rule base for compliance verification item by item, and a full-dimensional alignment verification of product-quantity-price-inventory is performed on multi-product orders; if a conflict is found during the verification, the minimum edit distance is used to resolve the conflict. Tracing back to the user's original input to pinpoint the root cause of the conflict, generating at least two actionable correction suggestions, and guiding the user to confirm the corrections through interactive dialogue; after all validations are passed, a JSON-formatted reservation order data object is generated.

[0013] In step S9, the multimodal fusion confirmation engine determines the final order content with the user's latest modifications as the highest priority; the pre-inspection rules of the risk control rule engine include: order amount exceeding the customer's historical single order average threshold, sales price lower than the agreed bottom price, customer credit limit nearing expiration, inventory shortage warning, and abnormal delivery cycle.

[0014] This invention also relates to an order generation system that implements an AI-driven conversational ERP order generation method, comprising: The wake-up module is used to detect wake-up commands and trigger dialogue processes, and includes a voice wake-up submodule and a graphical interface wake-up submodule. The permission loading module is used to load the current user's ERP permission configuration information immediately after wake-up and encapsulate it as a static permission vector; The behavior collection and proactive intent prediction module is used to collect users' historical behavior sequence data, construct behavior sequence vectors through a time-series coding model, predict order intent, and generate personalized dialogue guidance prompts; The intent parsing module is used to extract initial order elements from natural language input using a large language model; The dynamic context awareness module is used to maintain a joint constraint system of static permission vectors and dynamic context vectors, pre-match and optimize the initial order elements, and generate accurate order elements. The permission verification module is used to compare and verify the precise order elements with the ERP permission configuration information in real time, and generate guiding questions when the verification fails. The business data acquisition module is used to call the ERP master data interface to obtain real business data after the verification is passed, and generate a basic order dataset. The order structure parsing and conflict resolution module has a built-in structured constraint rule library. It is used to perform multi-dimensional alignment verification and conflict resolution on the basic order dataset based on the model output-rule bidirectional verification mechanism, and generate compliant pre-order data objects. The pre-order visualization module is used to render pre-order data objects into an interactive confirmation interface and to announce the core order information through voice synthesis. The multimodal fusion confirmation and risk control pre-inspection module is used to analyze the user's true intent by integrating multimodal signals from voice commands, interface operations, and corrective inputs, and simultaneously call the risk control rule engine to complete order pre-inspection, highlighting and highlighting risk items. The order execution module is used to respond to the final confirmation instruction, write the pre-order data object into the ERP database to generate a formal order, and synchronously update the user's historical behavior sequence data.

[0015] The advantages of this invention are: 1. This invention incorporates user permissions verification during the AI ​​intent parsing stage, preventing users from discovering insufficient permissions only after completing all input. When verification fails, the system can generate guiding questions based on permission data, providing optional suggestions and significantly improving interaction efficiency.

[0016] 2. After the authorization verification is passed, this invention directly obtains real business data such as price, inventory, credit limit, and delivery cycle from the ERP master data interface, instead of relying on AI model estimation, thus ensuring the accuracy of order data and eliminating the need for secondary verification by the user.

[0017] 3. This invention supports both voice wake-up and graphical interface wake-up. Voice wake-up is suitable for mobile devices and on-site operation scenarios, while graphical interface wake-up is suitable for PC operation scenarios, satisfying different usage habits.

[0018] 4. By using a joint constraint mechanism of static permission vectors and dynamic context vectors, the accuracy of multi-turn dialogue entity parsing is improved, enabling context-based intelligent matching, perfectly supporting user abbreviation and referential input, and significantly reducing user input costs.

[0019] 5. By using a conflict resolution mechanism that combines rules and models, the automatic generation success rate of complex orders with multiple products is improved. Conflict resolution is moved to the pre-order generation stage, completely avoiding order submission failures and significantly reducing manual correction costs.

[0020] 6. Through a multimodal fusion intent confirmation and risk control pre-inspection mechanism, the order error rate caused by environmental interference is reduced, risky orders are intercepted in advance, the invalid submission rate is reduced to zero, and the enterprise's risk control and compliance management requirements are met.

[0021] 7. A leap forward in interaction mode: The interaction model has been upgraded from passive, responsive to proactive, predictive, and personalized guidance based on user behavior sequences, significantly lowering the barrier to entry for new users. Internal testing has shown that the average time for salespeople to complete a simple sales order has been reduced, and user satisfaction has significantly improved. Attached Figure Description

[0022] Figure 1 This is a flowchart of the wake-up and permission loading process of the present invention.

[0023] Figure 2 This is a flowchart of the proactive intent prediction and dynamic context awareness of the present invention.

[0024] Figure 3 This is a flowchart of the intent parsing and permission verification process of the present invention.

[0025] Figure 4 This is a flowchart of the order structure analysis and conflict resolution process of the present invention.

[0026] Figure 5 This is a flowchart of the multimodal fusion verification and risk control pre-inspection process of the present invention.

[0027] Figure 6 This is a flowchart of the order confirmation and order placement process of the present invention.

[0028] Figure 7 This is a system diagram structural block diagram of the present invention. Detailed Implementation

[0029] The present invention will be further described below with reference to specific embodiments, and the advantages and features of the present invention will become clearer as a result. However, these embodiments are merely exemplary and do not constitute any limitation on the scope of the present invention. Those skilled in the art should understand that modifications or substitutions can be made to the details and form of the technical solutions of the present invention without departing from the spirit and scope of the present invention, but all such modifications and substitutions fall within the protection scope of the present invention.

[0030] See Figures 1 to 7 This invention relates to an AI-driven conversational ERP order generation method, comprising the following steps: Step S1: In response to the detected wake-up command, load the current user's ERP permission configuration information and synchronously collect the user's historical behavior sequence data; Step S2: Construct a behavior sequence vector based on the user's historical behavior sequence data, use a time-series coding model to predict the order intent and generate personalized dialogue guidance prompts, which are presented synchronously through interface bubbles and voice to complete the proactive dialogue initialization; if the user has no historical behavior sequence data, skip the proactive guidance step and directly enter the dialogue listening state, waiting for the user's natural language input. Step S3: Obtain the user's natural language input, and use a large language model combined with dialogue guidance prompts to extract initial order elements from the input text. The order elements include at least customer identifier, product identifier, and quantity. Step S4: Introduce a dynamic context awareness layer to maintain the joint constraints of the static permission vector and the dynamic context vector, and pre-match and optimize the initial order elements with the joint constraints to generate accurate order elements; Step S5: Compare and verify the precise order elements with the ERP permission configuration information in real time. The verification includes customer permission verification, product permission verification and regional permission verification. Step S6: If the verification passes, call the ERP master data interface to obtain the real business data associated with the order elements and generate the basic order dataset; Step S7: Based on the structured constraint rule base and the model output-rule bidirectional verification mechanism, perform multi-dimensional alignment verification and conflict resolution on the basic order dataset to generate compliant pre-order data objects; Step S8: Render the pre-order data object into a visual interactive confirmation interface, and broadcast the core order information through voice synthesis; Step S9: Analyze the user's true intent using multimodal signals from integrated voice commands, interface operations, and corrective inputs; simultaneously call the risk control rule engine to complete order pre-inspection; embed risk items into the confirmation interface for highlighting and key voice broadcasts; Step S10: In response to the user's final confirmation instruction, write the pre-order data object into the ERP database, generate a formal order and return the order number, and synchronously update the user's historical behavior sequence data; The method for constructing the behavior sequence vector in step S2 is as follows: The user's historical behavior sequence over the past T days is used as a reference. Input a temporal coding model Encoder, output a sequence vector of behaviors. The temporal coding model is a sequence coding network based on Transformer or BERT; in step S7, conflict resolution uses minimum edit distance to backtrack the user's original input, and the minimum edit distance... The calculation formula is: ; Where |a| and |b| represent the lengths of the input strings a and b, respectively. The function is an indicator; it takes the value 0 when two characters are the same, and 1 otherwise. In step S9, the multimodal fusion confirmation engine uses a large multimodal fusion model to synchronously collect voice commands. Interface operation and text input Semantic alignment and intent parsing are performed through an attention mechanism, and the fused feature representation is as follows: ,in This is a learnable weight matrix.

[0031] The temporal coding model used in step S2 of this invention is used to extract behavioral pattern vectors from the user's historical behavior sequence to predict order intent. This model is built based on the Transformer or BERT architecture, as detailed below: 1. Model Structure Input layer: Receives the user's historical behavior sequence over the past T days. Each It is a multi-dimensional feature vector that includes: operation type (browsing customer details, searching for products, adding to cart, submitting order, etc.), operation object ID (customer ID, product ID), dwell time, timestamp, etc.

[0032] Embedding layer: Maps discrete features (such as operation type, object ID) into dense vectors, which are then concatenated with continuous features to obtain the embedding vector at each time step. .

[0033] Encoder: A Transformer encoder with L=4 stacked layers is used. Each layer contains a multi-head self-attention network (h=8 heads) and a feedforward network (hidden dimensions d_model=256, d_ff=512), with layer normalization and residual connections. Alternatively, a shallow version of BERT can be used (sequence length T=7, maximum position encoding is 7).

[0034] Pooling layer: for the encoder output sequence Perform average pooling or take the [CLS] position output to obtain a fixed-dimensional behavior sequence vector. .

[0035] 2. Training methods Training data: A large number of historical operation sequences of users (authorized and anonymized) were collected from the ERP system logs, and the actual order intent of the users (i.e., the customer, product, and quantity in the final generated order) was manually or automatically labeled. A total of 100,000 complete operation-order pairs were collected.

[0036] Pre-training task (optional): Use a self-supervised next operation prediction task, randomly mask 15% of the time steps, predict the type of the masked operation, and use cross-entropy loss as the loss function.

[0037] Fine-tuning the task: As input, a fully connected layer outputs the intent category (joint classification / regression of customer ID, product ID, and quantity range), and the loss function is: Where c is the customer category, p is the product category, and q is the quantity.

[0038] Optimizer: AdamW, learning rate 1e-4, batch size=32, training for 20 epochs.

[0039] 3. Integration with ERP Scenario The operation object ID in the model input is directly associated with the unique identifier of the customer and product entity in the ERP master data, making the behavior sequence vector... It contains the user's interaction preferences with specific business entities.

[0040] The anticipated order intent is used to generate personalized dialogue prompts (such as "Do you need to create a sales order for Type A equipment for Shanghai XX Company?"), realizing an interactive upgrade from passive response to proactive prediction.

[0041] II. Integration of Large Language Model and Joint Constraints In steps S3 and S4, large language models (such as GPT-3.5, LLaMA 2-7B) are used to perform natural language intent parsing, and ERP permission constraints are injected through a dynamic context-aware layer.

[0042] 1. Basic configuration of a large language model It employs pre-trained lightweight large models (7B~13B parameters) and deploys them on enterprise internal servers or private clouds.

[0043] The input prompt template consists of three parts: system role setting ("You are an ERP order assistant"), combined constraint prompt (formed by the fusion of static permission vector and dynamic context vector), and user natural language input.

[0044] Output format requirements: Structured JSON, with fields including "customer" (customer identifier), "products" (product list), "quantities" (quantity list), and "total_amount" (total price, optional).

[0045] 2. Construction of conjunction constraint prompts Static permission vector Serialized to text: "The customers you can see are: [List of customer names]; the products available for sale are: [List of product names]; the jurisdiction is: [List of regions]." Dynamic Context Vector Serialized to text: "Your recently viewed customers: [Customer Name]; Current page: [Customer / Product Details Page]; Confirmed order elements in this round: [Extracted customers, products]; Historical high-frequency transaction entities: [Customer A, Product B]; Common reference mapping: 'Old Customer' -> Recently transacted customer, 'Frequently Used Products' -> Highest historical frequency product." Using the above text as a prefix suggestion for the large language model forces the model to prioritize parsing entities from the dynamic context and only search the full static permission list when no match is found.

[0046] 3. Fine-tuning (optional) We collected 5000 real user dialogue records (natural language input + manually corrected order elements) to construct training samples. We employed an instruction-based fine-tuning method, using autoregressive cross-entropy as the loss function, calculating the loss only on the output JSON portion. Fine-tuning was performed for 3 epochs with a learning rate of 5e-6.

[0047] III. Construction and Training of the Multimodal Fusion Confirmation Engine The multimodal fusion confirmation engine in step S9 is used to simultaneously parse voice commands, interface operations, and text correction input to determine the user's final confirmation intent.

[0048] 1. Model Structure Speech coding branch: Receives the raw speech waveform or MFCC features, extracts the text transcription using a pre-trained speech recognition model (such as Whisper Small), and outputs an acoustic feature vector. .

[0049] User interaction coding branch: User actions such as clicking, modifying, and deleting order cards are encoded into one-hot vector sequences, which are then mapped to action intent vectors via a fully connected layer. .

[0050] Text input encoding branch: Receives corrective input from the user in the text box (e.g., "change quantity to 20"), and obtains the text semantic vector through lightweight BERT encoding. .

[0051] Multimodal fusion layer: Employs a multi-head attention mechanism (h=4 heads), using features from three modalities as Query, Key, and Value inputs to calculate fused features. ; in The linear transformation matrix is ​​learnable. The attention output is then passed through a fully connected layer and a softmax layer to output the final confirmed content (keep the original order, modify the order, or cancel).

[0052] Priority rule: After the model is output, the system logic layer forces the latest user modification to be the highest priority (that is, if the timestamp of the interface operation is later than the voice command, the timestamp of the interface operation shall prevail) to ensure real-time response.

[0053] 2. Training methods Training data: Simulating an ERP order confirmation scenario, 20,000 multimodal interaction data points were collected. Each data point includes: a voice command (such as "Confirm" or "Modify quantity to 20"), a series of interface operations (such as clicking the "Modify" button and entering a number), text corrections, and manually annotated final order content.

[0054] Alignment processing: There is timestamp alignment between voice, interface operation, and text correction. The three signals corresponding to the same confirmation decision constitute a sample. If a certain modality is missing, the corresponding feature vector is set to zero.

[0055] Loss function: Cross-entropy loss, which identifies the difference between the predicted final order content and the actual order content. A consistency regularization term is also introduced to encourage semantic consistency between speech and text.

[0056] Optimizer: Adam, learning rate 1e-4, batch size=64, training for 10 epochs.

[0057] 3. Integration with ERP scenarios Order modifications in voice commands (such as "change type A equipment to 20 units") are directly mapped to the order line field in the order data structure.

[0058] Modification operations in the interface (such as clicking the "+" button) trigger real-time updates of the order data object.

[0059] Multimodal fusion ensures that even in noisy environments (where voice misrecognition is difficult), errors can still be corrected through the interface, and on mobile devices (where interface operation is inconvenient), errors can be quickly confirmed through voice, significantly reducing the order error rate.

[0060] IV. Application of Minimum Edit Distance in Conflict Resolution In step S7, the minimum edit distance is used to trace the root cause of the conflict between the user's original input and the system's calculated data. The specific combination method is as follows: 1. Conflict detection: When the total order amount calculated by the system (based on the actual price and quantity in the ERP system) is inconsistent with the total amount entered by the user, a backtracking mechanism is triggered.

[0061] 2. Backtracking Algorithm: Using the original string input by the user (e.g., "total price 12000 yuan") and the string calculated by the system ("total price 11500 yuan") as a and b respectively, calculate the minimum edit distance. It also records the editing path (insertion, deletion, and replacement operations), locating the specific differences in numeric characters.

[0062] 3. Correction suggestion generation: If the difference is due to user error (such as entering an extra "0"), it is recommended to correct it according to the system's calculated value.

[0063] If the discrepancy stems from the user's actual intention (e.g., a desired total price of 12,000 yuan), then the required adjustment quantity can be calculated by working backward: Let the original product set in the order be... Total system price User's target total price U, difference Find a way to adjust the quantity of a certain product using a greedy algorithm or dynamic programming. Make Generate suggestions to "make the product Quantity increase / decrease Taiwan to reach total price U".

[0064] 4. Output format: Generate at least two actionable correction suggestions, and ask the user for confirmation via voice and interface.

[0065] In step S1, the wake-up command includes a voice wake-up command and a graphical interface wake-up command. The voice wake-up command is triggered by a preset wake-up word, and the graphical interface wake-up command is triggered by a wake-up control in the user interface. Multimodal triggering methods are supported, allowing users to flexibly choose contactless voice wake-up or traditional graphical interface wake-up according to the usage scenario, significantly improving the system's usability and ease of operation in mobile devices, field operations, and other environments.

[0066] In step S1, the ERP permission configuration information includes the current user's visible customer list, salable product list, and jurisdiction list. In step S1, the permission configuration information is encapsulated into a static permission vector. , serving as the fundamental contextual constraints for large language models.

[0067] The following is an example illustrating the encapsulation of the static permission vector in step S1 and its use as a basic context constraint for a large language model: The ERP permission configuration for user "Li Si" is as follows: Visible customer list: Hangzhou XX Company; List of products available for sale: Type C consumables; List of jurisdictional areas: East China region.

[0068] The system encapsulates it as a static permission vector: Implemented permission verification beforehand to avoid invalid interactions: User voice input: "Please order 10 Type A devices for Beijing XX Company."

[0069] Traditional approach: AI first extracts "Beijing XX Company" and "Type A equipment", and only after the user confirms all of them does it verify permissions. If no permission is found, an error is reported and all the user's input is invalidated.

[0070] The solution of this invention: The static permission vector serves as the context constraint of the large model. When the model is parsed, it immediately discovers that "Beijing XX Company" is not in the list of visible customers and "Type A equipment" is not in the list of products available for sale. It then triggers a guiding question: "You do not have viewing permission for Beijing XX Company, nor do you have sales permission for Type A equipment. Would you like to switch to Hangzhou XX Company and Type C consumables?" — avoiding invalid user input.

[0071] Another example is improving the accuracy and compliance of entity resolution: The user entered: "Order 5 consumables for my old customer".

[0072] Traditional approach: The model may match "old customers" and "consumables" from the entire database, which may easily result in matching entities without the necessary permissions (such as "Shanghai XX Company" or "Type A equipment").

[0073] The solution of this invention is as follows: The static permission vector limits the candidate range to only "Hangzhou XX Company" and "C-type consumables". The model combines dynamic context (such as recently viewed customers) to accurately match "Hangzhou XX Company" and "C-type consumables", and the output order elements are naturally compliant without the need for subsequent secondary verification and correction.

[0074] User access data such as visible customers, salable products, and jurisdiction are encapsulated into static permission vectors and directly used as the basic context constraints of the large language model. This allows the model to perceive permission boundaries during the intent parsing stage, preventing the generation of unauthorized order elements from the source and preventing input from being invalidated due to insufficient permissions after the user completes the entire dialogue.

[0075] Static permission vectors provide the model with a clear range of candidate entities (e.g., resolving customers only from the visible customer list). Combined with subsequent dynamic context matching, this can significantly reduce the error rate of the model resolving user input as unauthorized entities, while ensuring that all generated order elements naturally meet enterprise-level permission compliance requirements.

[0076] The user historical behavior sequence data collected in step S1 includes: the user's order operation trajectory over the past 7 days, high-frequency transaction customers, frequently sold product list, current ERP interface context, historical order element preferences, and peak order placement time data. By collecting multi-dimensional historical behavior data such as the user's order operation trajectory over the past 7 days, high-frequency transaction customers, and frequently sold product list, the system provides a rich data foundation for subsequent proactive intent prediction and personalized guidance. This enables the system to accurately predict the user's most likely order intent and generate targeted dialogue prompts, thereby significantly reducing user input costs and significantly shortening order entry time.

[0077] If a user exhibits the following behavior within the past 7 days: He browsed the details page of "Shenzhen XX Company" and searched for "Type B accessories," subsequently creating an order for that customer; in the following days, he placed multiple orders for "Type A equipment" for "Shenzhen XX Company," with the order times concentrated between 9:30 AM and 10:30 AM each day. The system records that his high-frequency trading customers are "Shenzhen XX Company" and "Guangzhou YY Company," and his frequently sold products are "Type A equipment" and "Type B accessories." Currently, he is on the ERP order entry page, with the cursor in the customer name input box, and the system detects that frequently used customer recommendations are displayed in the lower right corner of the page. Furthermore, his historical order preference data shows that he prefers to select "expedited delivery" and "standard price list." Based on the above-collected order operation trajectory, high-frequency trading customers, frequently sold products, interface dwell context, order preference data, and peak order placement time data, in step S2, the system predicts that his most likely order intention is to create a sales order for "Type A equipment" for "Shenzhen XX Company" and proactively displays a guidance prompt to help him quickly complete the form.

[0078] The dynamic context vector in step S4 This includes the user's recently viewed customer list, the customer or product page currently viewed on the ERP interface, confirmed order elements from the current conversation, historical high-frequency transaction entities, and a matching entity library based on user-defined expressions; the joint constraints serve as prefix system hints for the large language model, prioritizing matching entities in the dynamic context vector, and if no valid match is found, falling back to a full matching of the static permission vector; the pre-matching optimization process is represented as... ,in This is the initial order element vector. This is an entity analytic function based on joint constraints.

[0079] In step S4, the system introduces a dynamic context-aware layer to accurately match abbreviated or referential expressions (such as "old customer," "frequently used product," "that model") in the user's initial order elements into standardized order elements. The core of this awareness layer is an entity resolution function based on joint constraints. The implementation method is as follows.

[0080] I. Dynamic Context Vectors Construction The dynamic context vector maintains the following five types of data in real time, with each data point carrying a timestamp and confidence weight: 1. List of customers recently viewed by the user: obtained from front-end tracking points, sorted in descending order of browsing time, with a maximum of 5 entries retained. Each entry contains customer ID, customer name, and browsing duration.

[0081] 2. The customer or product page currently displayed on the ERP interface: This is determined by monitoring the current browser tab URL or the focus of the ERP client interface. If the currently opened page is a customer details page or a product details page, the corresponding entity ID is extracted.

[0082] 3. Order elements confirmed in this round of dialogue: In this dialogue session, the user has clearly confirmed (through voice or interface) information such as customer, product, quantity, etc., which is stored as a session-level cache.

[0083] 4. Historical high-frequency trading entities: These are statistically derived from the user's historical behavior sequence collected in step S1 over the past 7 days, such as the top 3 high-frequency trading customers and the top 3 frequently sold products.

[0084] 5. User-defined referential representation matching entity library: a pre-built referential mapping table that supports dynamic learning. For example: "Returning Customers" → Customers with the most transactions in the last 7 days (dynamically calculated); "Frequently Used Products" → The products with the highest sales volume in the last 7 days; "This Customer" → The customer currently on the ERP screen; "The last one" → The customer / product corresponding to the most recent order.

[0085] The above data is encapsulated as a dynamic context vector in JSON format. .

[0086] II. Entity Analytical Functions Based on Joint Constraints Implementation The entity parsing function adopts a hybrid strategy: it prioritizes rule matching based on dynamic context, and when rule matching fails or there is ambiguity, it calls the lightweight BERT entity linking model for semantic matching, and finally uses the static permission vector as a fallback constraint.

[0087] 2.1 Rule Matching Layer (Highest Priority) For input For each entity representation e (such as the customer identifier "old customer"), the exact mapping is first searched in the "matching entity library of user-referenced representations". If a match is found, the corresponding standardized entity ID is returned directly.

[0088] If the description is the same as the entity name in "Confirmed Order Elements in this Round of Dialogue", then the confirmed entity will be returned.

[0089] If the description is the same as the entity name in "the customer or product page currently displayed on the ERP interface" or is a specific reference (such as "this customer"), then return to that entity page.

[0090] If the expression is a partial match (such as "Shenzhen company"), then a fuzzy string match (cosine similarity threshold of 0.8) is performed in "the user's recently viewed customer list" and "historical high-frequency trading entities", and the result with the highest score and uniqueness is taken.

[0091] 2.2 Entity Linking Model Layer (When rule matching fails or there is no unique result) When rule matching cannot determine a unique entity (for example, the input "General Manager Li" may correspond to multiple customers), the pre-trained BERT entity linking model is invoked. The model structure is as follows: Input: A natural language sentence entered by the user (e.g., "Give Mr. Li 10 Type A devices") and a list of candidate entities (from a static permission vector). (List of visible customer names extracted).

[0092] Model structure: Based on BERT-base-chinese (12 layers, 768 dimensions), a binary classifier is connected after the [CLS] output to determine the relevance between the input sentence and each candidate entity.

[0093] The specific method is as follows: the sentence and the candidate entity name are concatenated into "[CLS] sentence[SEP] candidate entity name[SEP]", which is then encoded by BERT and the [CLS] vector is obtained. The vector is then passed through a fully connected layer and a sigmoid function to output the relevant probabilities.

[0094] Training data: 100,000 labeled data entries were collected from the ERP historical dialogue logs. Each data entry includes the user input sentence, candidate entity name, and a label indicating whether it matches (positive to negative sample ratio 1:3). Negative samples were randomly sampled from entities without permissions or semantically irrelevant entities.

[0095] Training parameters: learning rate 2e-5, batch size 32, training for 3 epochs, optimizer AdamW, loss function is binary cross-entropy.

[0096] Reasoning: Calculate the relevant probability for each candidate entity, and select the entity with the highest probability that is greater than the threshold of 0.7 as the matching result. If the highest probability is lower than 0.7, it is considered that there is no valid match.

[0097] 2.3 Static permission vector fallback If neither of the above two layers yields a valid match, then the process falls back to the static permission vector. Full Match: Perform an exact or fuzzy match on the visible customer list or the list of available products (using edit distance, with a threshold of 2). If no match is found, trigger the guiding question in step S5 (e.g., "No customer was found. Would you like to select from the following list:...").

[0098] III. Joint constraints as prefix system hints for large language models Before performing the large language model parsing in step S3, the system will statically assign permission vectors. and dynamic context vector The fusion is performed as a natural language prefix suggestion, which is then appended as a system message to the beginning of the large model input. The fusion rule is as follows: Prioritize describing entities that are explicitly available in the dynamic context: "You recently viewed a customer of Shenzhen XX Company; you are currently viewing the product page of Guangzhou YY Company; your frequently sold product is Type A equipment." Then add the static permission boundaries: "Your range of marketable products also includes Type B accessories and Type C consumables." Finally, the system provides a mapping explanation: "When you say 'old customer,' the system will interpret it as Shenzhen XX Company; when you say 'frequently used product,' it will interpret it as Type A equipment." This prefix hint guides the large model to automatically favor entities in the dynamic context when extracting initial order elements, thus outputting more accurate results. This reduces the burden of subsequent parsing.

[0099] IV. Output of Pre-matching Optimization After the above After function processing, the initial order element vector (This may contain vague descriptions such as "old customers" or "10 frequently used products") and is converted into a standardized, precise order element vector. ,For example: enter ; Output Customer ID: “C001”, Customer Name: “Shenzhen XX Company”, Product ID: “P001”, Product Name: “Type A Equipment”, Quantity: }; This precise order element is directly used for permission verification in step S5 and business data acquisition in step S6.

[0100] The real-time comparison and verification in step S5 specifically includes: The extracted customer identifiers are matched against the list of visible customers. If the match fails, the cosine similarity of the customer names is calculated, and a guiding question containing similar customer names is generated. The extracted product identifier is matched with the list of available products. If the match fails, a guiding question containing alternative products is generated. The system matches the region field in the customer's master data with the list of governed regions. If the match fails, an insufficient permissions message is generated.

[0101] When a customer identifier or product identifier fails to match, the system does not directly report an error and terminate the process. Instead, it calculates the cosine similarity or provides alternative product suggestions and generates guiding questions (such as "Switch to XX customer?" or "Check alternative product YY?") to allow users to quickly correct the error instead of re-entering the information, significantly improving the order completion rate.

[0102] By employing a three-tiered parallel verification system (customer, product, and region), mandatory permission filtering is performed before data enters the ERP system. In particular, the region permission verification, combined with the region field in the customer's master data, effectively prevents unauthorized order submissions due to unclear permission boundaries, ensuring enterprise data security and compliance management requirements.

[0103] In step S6, the real business data includes: precise prices obtained from the ERP price master data, real-time inventory levels obtained from the ERP inventory module, customer credit limits obtained from the ERP credit management module, and standard delivery cycles obtained from the ERP delivery management module; the process of generating the basic order dataset is as follows: refining order elements... Used as a query key to call the ERP master data interface function. Returns a multi-dimensional business data vector containing price, inventory, credit limit, and delivery time. .

[0104] Real-time prices, inventory, credit limits, and delivery cycles are obtained directly from the ERP master data interface, avoiding data bias caused by relying on large model estimations. This eliminates the need for secondary verification by users, significantly improving the credibility of order data and business compliance.

[0105] The returned multidimensional business data vector (price, inventory, credit, delivery cycle) serves as the benchmark for conflict resolution in the subsequent step S7, ensuring that all verifications (such as whether the inventory is sufficient, whether the amount exceeds the credit limit, and whether the delivery cycle is compliant) are based on real-time and accurate business data, fundamentally avoiding order submission failures due to inaccurate data.

[0106] In step S7, the structured constraint rule base includes: order line product code uniqueness rules, order quantity non-negative rules, sales price not lower than the agreed floor price rules, available inventory greater than or equal to the order quantity rules, total order amount not exceeding the customer's available credit limit rules, and delivery cycle compliance rules; the model output-rule bidirectional verification mechanism is as follows: first, the basic order dataset is input into the rule base for compliance verification item by item, and a full-dimensional alignment verification of product-quantity-price-inventory is performed on multi-product orders; if a conflict is found during the verification, the minimum edit distance is used to resolve the conflict. Tracing back to the user's original input to pinpoint the root cause of the conflict, generating at least two actionable correction suggestions, and guiding the user to confirm the corrections through interactive dialogue; after all verifications are successful, a JSON-formatted reservation order data object is generated.

[0107] The rule base covers key business constraints such as product code uniqueness, non-negative quantity, price not lower than the base price, sufficient inventory, credit limit not exceeding the limit, and compliant delivery cycle, ensuring the legality and enforceability of order data from multiple dimensions and avoiding subsequent process failures due to data errors.

[0108] When a conflict is detected during verification, the system traces back the user's original input by using the minimum edit distance to accurately locate the root cause of the conflict and generate at least two actionable correction suggestions. Users only need to select one instead of re-entering the information, which greatly reduces the cost of manual investigation and correction.

[0109] Suppose the base order dataset contains the following multi-product orders: Product A: Quantity 10 units, unit price 1000 yuan, subtotal 10000 yuan, 15 units in stock; Product B: Quantity 5 units, unit price 300 yuan, subtotal 1500 yuan, 8 units in stock; Customer available credit limit: 50000 yuan; Total order price mentioned in the user's original input: 12000 yuan.

[0110] The system loads the structured constraint rule library and validates each rule individually: Product code uniqueness: Passed (no duplicates).

[0111] Non-negative quantity: Passed.

[0112] Price not lower than the base price: Pass (1000 ≥ base price 900, 300 ≥ base price 280).

[0113] Sufficient inventory: Passed (15≥10, 8≥5).

[0114] Credit limit: Approved (11500 ≤ 50000).

[0115] Delivery cycle: Passed (3 days for Type A equipment, 2 days for Type B parts, both meet the standards).

[0116] Conflict: The system calculates the total order amount as 11,500 yuan, but the user entered a total of 12,000 yuan, a difference of 500 yuan.

[0117] The system uses the minimum edit distance \text{EditDist}(a,b) to trace back the user's original input string "total price 12000 yuan" and the system's calculated string "total price 11500 yuan", locating the difference between the numeric characters "2" and "1". Based on this, two correction suggestions are generated: 1. An order is generated based on the system's calculated total price of 11,500 yuan; 2. Increase the quantity of product A by 1 unit (increase by 1000 yuan) or increase the quantity of product B by 2 units (increase by 600 yuan) to approach 12000 yuan, and suggest specific adjustment plans.

[0118] The system prompts the user via voice and interface: "There is a difference between the total order price of 12,000 yuan you entered and the 11,500 yuan calculated by the system. You can choose: 1. Generate an order based on the total price of 11,500 yuan calculated by the system; 2. Adjust the quantity of product A to 11 units, and the total price will become 12,500 yuan." After the user selects option 1, the conflict resolution is completed, and the system generates a JSON-formatted reservation order data object for step S8 to render and confirm.

[0119] In step S9, the multimodal fusion confirmation engine prioritizes the user's latest modifications to determine the final order content. The risk control rule engine's pre-detection rules include: order amount exceeding the customer's historical average single order threshold, sales price below the agreed floor price, customer credit limit nearing expiration, inventory shortage warning, and abnormal delivery cycle. Simultaneously collecting three types of signals—voice commands, interface operations, and text corrections—and prioritizing the user's latest modifications effectively solves the confirmation error problem of single-modal (voice only or interface only) responses in noisy environments or accidental operation scenarios, significantly reducing the order error rate.

[0120] Before the user makes a final confirmation, the system completes risk control rule checks such as order amount exceeding the threshold, price below the base price, credit limit approaching the limit, insufficient inventory, and abnormal delivery cycle. Risk items are highlighted on the confirmation screen and emphasized with voice broadcast, so that users are fully aware of potential risks before confirmation, avoid invalid submissions, and meet the company's compliance management requirements.

[0121] This embodiment uses the OntoSync ERP system as an application scenario to describe the specific implementation of an AI-driven conversational ERP order generation method.

[0122] like Figure 1The diagram illustrates the wake-up and permission loading process. The system continuously monitors wake-up signals. When it detects the user uttering the preset voice wake-up phrase "Wu Ge Wu Ge," it triggers voice wake-up; or when it detects the user clicking the "AI Assistant" button in the graphical user interface, it triggers graphical interface wake-up. After wake-up, the system obtains the currently logged-in user's identifier and queries the user's permission configuration information from the ERP permission center. The permission configuration information includes three parts: a list of visible customers (e.g., "Shanghai XX Company, Jiangsu XX Company, Zhejiang XX Company"), a list of salable products (e.g., "Type A equipment, Type B accessories, Type C consumables"), and a list of jurisdictional regions (e.g., "East China Region"). The system encapsulates this permission configuration information into a static permission vector, serving as a system-level constraint for subsequent large-scale model calls; it also synchronously collects the user's historical behavior sequence data, including frequent browsing of the Shanghai XX Company details page in the past 7 days, 90% of historical orders being Type A equipment and Type B accessories, and the most recent order being Type A equipment from Shanghai XX Company.

[0123] Figure 2 illustrates the process of proactive intent prediction and dynamic context awareness. The system encodes user behavior sequence data using a temporal coding model to construct a behavior sequence vector. After inputting this vector into the large model, the system predicts the user's core intent as "to create a sales order for Type A equipment for Shanghai XX Company." A personalized guidance prompt is then generated, displayed as a floating bubble on the interface: "Do you need to create a sales order for Type A equipment for Shanghai XX Company?" This prompt is simultaneously read aloud via speech synthesis. If the user replies "yes" via voice, the initial order elements are directly generated. If the user inputs new natural language, such as "Please place an order for 10 Type A equipment units and 5 Type B accessories for an existing customer, totaling 12,000 yuan," the system proceeds to the intent parsing stage.

[0124] The intent parsing module uses a large model combined with joint constraint prompts to extract initial order elements: customer entity "existing customer", product entity "Type A equipment, Type B accessories", quantity entities "10, 5", and total price entity "12,000 yuan". The dynamic context awareness layer, through the joint constraint system, prioritizes matching "existing customer" to the most recently viewed Shanghai XX Company in the dynamic context vector, completing entity completion and generating precise order elements: customer "Shanghai XX Company", product "Type A equipment, Type B accessories", quantity "10 units, 5 items", and total price "12,000 yuan".

[0125] like Figure 3 The diagram illustrates the intent parsing and permission verification process. The permission verification module performs three layers of verification in parallel: The first layer is customer permission verification. The customer entity "Shanghai XX Company" is matched against the visible customer list, using a fuzzy matching algorithm to support abbreviations and synonyms. If a match is successful, the process proceeds to the second layer; if a match fails, the system doesn't simply display an error message, but instead searches the visible customer list for similar names and generates a guiding question: "You do not have viewing permissions for 'Shanghai XX Company,' would you like to switch to 'Shanghai YY Company'?" The second layer is product permission verification. It matches the product entities "Type A Equipment, Type B Accessories" with the list of available products. If the match is successful, proceed to the third layer; if the match fails, a guiding question is generated: "You do not have sales permission for 'Type A Equipment'. Would you like to view the alternative product 'Type C Equipment'?" The third layer is regional permission verification. Based on the shipping region field in the customer's master data, it determines whether the customer belongs to the user's jurisdiction list. If they do, the verification passes; otherwise, it indicates insufficient permissions.

[0126] After all verifications pass, the system calls the ERP master data interface to obtain the actual business data: from the price master data, it obtains the agreed unit price of type A equipment of 1,000 yuan / unit and the agreed unit price of type B accessories of 300 yuan / piece for this customer; from the inventory module, it obtains the current available inventory of type A equipment of 15 units and available inventory of type B accessories of 8 units; from the credit management module, it obtains the available credit limit of 50,000 yuan for this customer, and generates the basic order dataset.

[0127] like Figure 4 The diagram illustrates the order structure parsing and conflict resolution process. The system loads a structured constraint rule library and performs bidirectional validation on the basic order dataset. Product-Quantity-Price Alignment Validation: 10 Type A devices with a total price of 10,000 yuan and 5 Type B accessories with a total price of 1,500 yuan, for a total amount of 11,500 yuan, which conflicts with the 12,000 yuan entered by the user. Inventory verification: Type A equipment inventory is ≥10 units (15 units), and Type B spare parts inventory is ≥5 units (8 units), which meets the requirements; Credit limit verification: The total order amount of 11,500 yuan is less than or equal to the available credit limit of 50,000 yuan, which meets the requirements. Price compliance verification: The unit price is not lower than the agreed floor price and complies with the rules.

[0128] Regarding the conflicting total amount, the system traces back the user's input using the minimum edit distance and generates two correction suggestions. The system then prompts the user via both voice and interface: "There is a difference between the total order price of 12,000 yuan you entered and the 11,500 yuan calculated by the system. You can choose: 1. Generate the order according to the system's calculated total price of 11,500 yuan; 2. Adjust the product quantity to match the total price of 12,000 yuan." If the user confirms the first option, the system resolves the conflict and generates a JSON-formatted pre-order data object.

[0129] Figure 5 illustrates the multimodal fusion confirmation and risk control pre-inspection process. The system renders the pre-order data object into an interactive confirmation interface, displaying order details in card format, including product name, quantity, unit price, and total price, and providing three operation buttons: "Confirm," "Modify," and "Cancel." Simultaneously, it announces via voice synthesis: "An order from Shanghai XX Company has been prepared for you, consisting of 10 Type A devices and 5 Type B accessories, with a total price of 11,500 yuan. Please confirm." Simultaneously collecting multimodal signals, if the user changes the quantity of Type A devices to 20 units on the interface and simultaneously replies "Confirm" via voice, the system analyzes the data using a multimodal fusion model, prioritizing the latest modification on the interface and updating the order quantity to 20 units. Simultaneously, the risk control rule engine is invoked for pre-checking, identifying two risk items: 1. There are 15 available Type A devices, but the order quantity is 20, indicating insufficient inventory; 2. The total order amount is 21,500 yuan, exceeding the customer's historical average single order value of 12,000 yuan by 79%. The system then highlights these two risk items on the confirmation interface and simultaneously announces via voice: "Your modified order quantity for Type A devices is 20 units, but the current available inventory is only 15 units, indicating insufficient inventory; the total order price is 21,500 yuan, exceeding the customer's historical average single order value by 79%. Please confirm." Figure 6 illustrates the order confirmation and execution process. After the user confirms the change of the quantity of Type A equipment to 15 units, the system updates the pre-order data object. The user then issues a final confirmation command (either via voice reply "confirm" or by clicking the confirmation button on the interface). The system calls the ERP sales order interface to write the pre-order data object into the ERP database, generating a formal order and returning the order number "SO20260324001" for the user to keep. Simultaneously, the system updates the user behavior sequence data, completing the entire process.

[0130] This invention also relates to an order generation system that implements an AI-driven conversational ERP order generation method, comprising: Wake-up module 1 is used to detect wake-up commands and trigger dialogue processes. It includes a voice wake-up submodule and a graphical interface wake-up submodule. It supports both voice wake-up and graphical interface wake-up. Users can flexibly choose contactless or traditional triggering methods according to the scenario, which significantly improves the usability and convenience of the system in different working environments.

[0131] Permission loading module 2 is used to immediately load the current user's ERP permission configuration information after wake-up and encapsulate it into a static permission vector; when the dialogue process starts, it immediately loads the user's permissions and encapsulates them into a static permission vector as a context constraint of the large model, realizes permission verification in advance, and avoids the generation of unauthorized order elements from the source.

[0132] The behavior collection and proactive intent prediction module 3 is used to collect users' historical behavior sequence data, construct behavior sequence vectors through a time-series coding model, predict order intent, and generate personalized dialogue guidance prompts; it analyzes users' historical behavior sequences through a time-series coding model, proactively predicts order intent, and generates personalized guidance prompts, changing passive response to proactive prediction, and significantly reducing the time spent on order entry.

[0133] The intent parsing module 4 is used to extract initial order elements from natural language input using a large language model. It accurately extracts order elements such as customers, products, and quantities from natural language using a large language model, supports conversational and simplified input, and significantly reduces the user's operation threshold and input cost.

[0134] The dynamic context awareness module 5 is used to maintain the joint constraint system of static permission vectors and dynamic context vectors, pre-match and optimize the initial order elements to generate accurate order elements; it maintains the joint constraints of static permissions and dynamic context, and prioritizes matching real-time information such as the user's most recently viewed, currently occupied, and confirmed elements, which significantly improves the accuracy of entity parsing of referential expressions.

[0135] The permission verification module 6 is used to compare and verify the precise order elements with the ERP permission configuration information in real time, and generate guiding questions when the verification fails. It performs three-level parallel verification of customers, products and regions, and generates guiding questions containing similar customers or alternative products when the matching fails, so as to avoid process interruption and improve order completion rate.

[0136] The business data acquisition module 7 is used to call the ERP master data interface to obtain real business data after the verification is passed, and generate a basic order dataset. It directly obtains real business data such as real-time price, inventory, credit limit, and delivery cycle from the ERP master data interface, eliminating AI estimation errors and ensuring the accuracy and reliability of order data.

[0137] The Order Structure Parsing and Conflict Resolution Module 8 has a built-in structured constraint rule library. It is used to perform multi-dimensional alignment verification and conflict resolution on the basic order dataset based on the model output-rule bidirectional verification mechanism, and generate compliant pre-order data objects. The built-in structured constraint rule library, combined with the minimum edit distance backtracking algorithm, automatically detects and intelligently resolves conflicts such as order amount, inventory, and credit, and generates actionable correction suggestions.

[0138] The reservation visualization module 9 is used to render reservation data objects into an interactive confirmation interface and announce the core information of the order through voice synthesis. It renders reservation data into an interactive confirmation interface and announces the core information in voice simultaneously, supports online editing and one-click modification by users, and improves the intuitiveness and operational efficiency of the confirmation process.

[0139] The multimodal fusion confirmation and risk control pre-inspection module 10 is used to analyze the user's true intent by integrating multimodal signals from voice commands, interface operations, and corrective inputs. It simultaneously calls the risk control rule engine to complete order pre-inspection, highlighting and highlighting risk items. By integrating voice, interface, and text signals, it prioritizes the user's latest modifications and simultaneously completes risk control pre-inspection and highlights risk items, reducing the order error rate by more than 80% and achieving proactive risk interception.

[0140] Order execution module 11 is used to respond to the final confirmation instruction, write the pre-order data object into the ERP database to generate a formal order, and synchronously update the user's historical behavior sequence data. Responding to the final confirmation instruction by writing the order into the ERP database and synchronously updating the user's historical behavior sequence forms a complete data loop, providing continuous data support for subsequent proactive intent prediction and model optimization.

[0141] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. An AI-driven conversational ERP order generation method, characterized in that, Includes the following steps: Step S1: In response to the detected wake-up command, load the current user's ERP permission configuration information and synchronously collect the user's historical behavior sequence data; Step S2: Construct a behavior sequence vector based on the user's historical behavior sequence data, use a time-series coding model to predict the order intent and generate personalized dialogue guidance prompts, and present them synchronously through interface bubbles and voice to complete the initialization of proactive dialogue; If the user has no historical behavior sequence data, skip the active guidance step and directly enter the dialogue listening state, waiting for the user's natural language input; Step S3: Obtain the user's natural language input, and use a large language model combined with dialogue guidance prompts to extract initial order elements from the input text. The order elements include at least customer identifier, product identifier, and quantity. Step S4: Introduce a dynamic context awareness layer to maintain the joint constraints of the static permission vector and the dynamic context vector, and pre-match and optimize the initial order elements with the joint constraints to generate accurate order elements; Step S5: Compare and verify the precise order elements with the ERP permission configuration information in real time. The verification includes customer permission verification, product permission verification and regional permission verification. Step S6: If the verification passes, call the ERP master data interface to obtain the real business data associated with the order elements and generate the basic order dataset; Step S7: Based on the structured constraint rule base and the model output-rule bidirectional verification mechanism, perform multi-dimensional alignment verification and conflict resolution on the basic order dataset to generate compliant pre-order data objects; Step S8: Render the pre-order data object into a visual interactive confirmation interface, and broadcast the core order information through voice synthesis; Step S9: Analyze the user's true intent using multimodal signals from integrated voice commands, interface operations, and corrective inputs; simultaneously call the risk control rule engine to complete order pre-inspection; embed risk items into the confirmation interface for highlighting and key voice broadcasts; Step S10: In response to the user's final confirmation instruction, write the pre-order data object into the ERP database, generate a formal order and return the order number, and synchronously update the user's historical behavior sequence data; The method for constructing the behavior sequence vector in step S2 is as follows: The user's historical behavior sequence over the past T days is used as a reference. Input a temporal coding model Encoder, output a sequence vector of behaviors. The temporal coding model is a sequence coding network based on Transformer or BERT; in step S7, conflict resolution uses minimum edit distance to backtrack the user's original input, and the minimum edit distance... The calculation formula is: ； Where |a| and |b| represent the lengths of the input strings a and b, respectively. The function is an indicator; it takes the value 0 when two characters are the same, and 1 otherwise. In step S9, the multimodal fusion confirmation engine uses a large multimodal fusion model to synchronously collect voice commands. Interface operation and text input Semantic alignment and intent parsing are performed through an attention mechanism, and the fused feature representation is as follows: ,in This is a learnable weight matrix.

2. The AI-driven conversational ERP order generation method according to claim 1, characterized in that, In step S1, the wake-up command includes a voice wake-up command and a graphical interface wake-up command. The voice wake-up command is triggered by a preset wake-up word, and the graphical interface wake-up command is triggered by a wake-up control in the user interface.

3. The AI-driven conversational ERP order generation method according to claim 1, characterized in that, In step S1, the ERP permission configuration information includes the current user's visible customer list, salable product list, and jurisdiction list. In step S1, the permission configuration information is encapsulated into a static permission vector. , serving as the fundamental contextual constraints for large language models.

4. The AI-driven conversational ERP order generation method according to claim 1, characterized in that, The user historical behavior sequence data collected in step S1 includes: the user's order operation trajectory in the past 7 days, high-frequency transaction customers, list of frequently sold products, current ERP interface stay context, historical order element preferences and peak order placement time data.

5. The AI-driven conversational ERP order generation method according to claim 1, characterized in that, The dynamic context vector in step S4 This includes the user's recently viewed customer list, the customer or product page currently viewed on the ERP interface, confirmed order elements from the current conversation, historical high-frequency transaction entities, and a matching entity library based on user-defined expressions; the joint constraints serve as prefix system hints for the large language model, prioritizing matching entities in the dynamic context vector, and if no valid match is found, falling back to a full matching of the static permission vector; the pre-matching optimization process is represented as... ,in This is the initial order element vector. This is an entity analytic function based on joint constraints.

6. The AI-driven conversational ERP order generation method according to claim 3, characterized in that, The real-time comparison and verification in step S5 specifically includes: The extracted customer identifiers are matched against the list of visible customers. If the match fails, the cosine similarity of the customer names is calculated, and a guiding question containing similar customer names is generated. The extracted product identifier is matched with the list of available products. If the match fails, a guiding question containing alternative products is generated. The system matches the region field in the customer's master data with the list of governed regions. If the match fails, an insufficient permissions message is generated.

7. The AI-driven conversational ERP order generation method according to claim 1, characterized in that, In step S6, the real business data includes: precise prices obtained from the ERP price master data, real-time inventory levels obtained from the ERP inventory module, customer credit limits obtained from the ERP credit management module, and standard delivery cycles obtained from the ERP delivery management module; the process of generating the basic order dataset is as follows: refining order elements... Used as a query key to call the ERP master data interface function. Returns a multi-dimensional business data vector containing price, inventory, credit limit, and delivery time. .

8. The AI-driven conversational ERP order generation method according to claim 1, characterized in that, In step S7, the structured constraint rule base includes: order line product code uniqueness rules, order quantity non-negative rules, sales price not lower than the agreed floor price rules, available inventory greater than or equal to the order quantity rules, total order amount not exceeding the customer's available credit limit rules, and delivery cycle compliance rules; the model output-rule bidirectional verification mechanism is as follows: first, the basic order dataset is input into the rule base for compliance verification item by item, and a full-dimensional alignment verification of product-quantity-price-inventory is performed on multi-product orders; if a conflict is found during the verification, the minimum edit distance is used to resolve the conflict. Tracing back to the user's original input to pinpoint the root cause of the conflict, generating at least two actionable correction suggestions, and guiding the user to confirm the corrections through interactive dialogue; after all validations are passed, a JSON-formatted reservation order data object is generated.

9. The AI-driven conversational ERP order generation method according to claim 1, characterized in that, In step S9, the multimodal fusion confirmation engine determines the final order content with the user's latest modifications as the highest priority; The pre-detection rules of the risk control rule engine include: order amount exceeding the average threshold of a customer's historical single order, sales price lower than the agreed bottom price, customer credit limit approaching the limit, inventory shortage warning, and abnormal delivery cycle.

10. A system for generating multiple orders using the AI-driven conversational ERP order generation method according to any one of claims 1 to 9, characterized in that, include: The wake-up module is used to detect wake-up commands and trigger dialogue processes, and includes a voice wake-up submodule and a graphical interface wake-up submodule. The permission loading module is used to load the current user's ERP permission configuration information immediately after wake-up and encapsulate it as a static permission vector; The behavior collection and proactive intent prediction module is used to collect users' historical behavior sequence data, construct behavior sequence vectors through a time-series coding model, predict order intent, and generate personalized dialogue guidance prompts; The intent parsing module is used to extract initial order elements from natural language input using a large language model; The dynamic context awareness module is used to maintain a joint constraint system of static permission vectors and dynamic context vectors, pre-match and optimize the initial order elements, and generate accurate order elements. The permission verification module is used to compare and verify the precise order elements with the ERP permission configuration information in real time, and generate guiding questions when the verification fails. The business data acquisition module is used to call the ERP master data interface to obtain real business data after the verification is passed, and generate a basic order dataset. The order structure parsing and conflict resolution module has a built-in structured constraint rule library. It is used to perform multi-dimensional alignment verification and conflict resolution on the basic order dataset based on the model output-rule bidirectional verification mechanism, and generate compliant pre-order data objects. The pre-order visualization module is used to render pre-order data objects into an interactive confirmation interface and to announce the core order information through voice synthesis. The multimodal fusion confirmation and risk control pre-inspection module is used to analyze the user's true intent by integrating multimodal signals from voice commands, interface operations, and corrective inputs, and simultaneously call the risk control rule engine to complete order pre-inspection, highlighting and highlighting risk items. The order execution module is used to respond to the final confirmation instruction, write the pre-order data object into the ERP database to generate a formal order, and synchronously update the user's historical behavior sequence data.

Images