Electronic transaction order generation method, electronic equipment and storage medium

Abstract

The invention provides an electronic transaction order generation method, electronic equipment and a storage medium. According to the embodiment of the invention, the method comprises the steps: obtaining a session message which carries a file and is sent in a transaction session, calling a multi-modal recognition model to analyze a target file carried by the session message, and recognizing whether the target file is a transaction intention file or not according to the analysis result of the target file; under the condition that the target file is a transaction intention file, generating page view data of an order guide page according to an analysis result of the target file; and pushing the page view data to at least one session end participating in the transaction session, so as to load an order guide page loaded based on the page view data at the pushed session end, and guide and confirm the electronic transaction order based on the content of the guide page. Compared with a traditional scheme, the probability of manual errors is reduced, the order placing efficiency is improved, the path from communication to order placing is remarkably shortened, and an accurate and efficient analysis result is obtained through the multi-modal recognition model.

Description

Technical Field

[0001] This application relates to the field of e-commerce technology, and in particular to a method for generating electronic transaction orders, a method for processing electronic transaction orders, electronic devices, storage media, and computer program products. Background Technology

[0002] In current cross-border B2B (business-to-business) e-commerce platforms, after the two parties (buyer and seller) communicate and reach a transaction agreement, the seller usually needs to create an order protected by the platform based on the consensus of both parties, send the order to the buyer, and prompt the buyer to complete the payment.

[0003] The order creation process described above can be divided into two schemes. One scheme involves the seller manually filling in information such as product details, price, logistics, and terms in the e-commerce platform's backend. This scheme relies on the seller's proactive and accurate operation, which is cumbersome, inefficient, and prone to errors. The other scheme involves creating orders using templates, such as batch importing from Excel templates. While this can improve batch processing efficiency, the seller still needs to organize and verify the data entered, resulting in lower efficiency. Furthermore, in the implementation of both schemes, buyer participation is low, awareness is weak, conversion rates are low, and the conversion path is easily interrupted. This can lead to transactions that have reached a commercial agreement being lost outside the platform's supervision and service system, preventing buyers from enjoying the transaction guarantees and financial services provided by the platform. Summary of the Invention

[0004] This application provides a method for generating electronic transaction orders, a method for processing electronic transaction orders, an apparatus, an electronic device, a storage medium, and a computer program product to solve one or more of the aforementioned technical problems.

[0005] In a first aspect, embodiments of this application provide a method for generating electronic transaction orders, comprising: acquiring a session message carrying a file sent in a transaction session; calling a multimodal recognition model to parse the target file carried in the session message, and identifying whether the target file is a transaction intention file based on the parsing result of the target file; if the target file is a transaction intention file, generating page view data of an order guidance page based on the parsing result of the target file; pushing the page view data to at least one session terminal participating in the transaction session, so as to load an order guidance page based on the page view data on the pushed session terminal, and guiding the confirmation of the electronic transaction order based on the content of the guidance page.

[0006] Secondly, embodiments of this application provide a method for processing electronic transaction orders, comprising: receiving a session message carrying a file sent by a seller in a transaction session; receiving page view data of an order guidance page, wherein the page view data is generated based on the parsing result of a target file carried in the session message, the page view data being generated when the target file is identified as a transaction intention file based on the parsing result of the target file, the target file being parsed by calling a multimodal recognition model; loading an order guidance page based on the page view data, and guiding the confirmation of the electronic transaction order based on the content of the order guidance page.

[0007] Thirdly, embodiments of this application provide an electronic device, including a memory, a processor, and a computer program stored in the memory, wherein the processor implements the above-described method when executing the computer program.

[0008] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0009] Fifthly, embodiments of this application provide a computer program product, wherein the computer program product includes a computer program that, when executed by a processor, implements the above-described method.

[0010] According to the embodiments of this application, a session message carrying a file sent in a transaction session is obtained; a multimodal recognition model is called to parse the target file carried in the session message; and the parsing result of the target file is used to identify whether the target file is a transaction intention file. If the target file is a transaction intention file, page view data for an order guidance page is generated based on the parsing result of the target file. The page view data is pushed to at least one session terminal participating in the transaction session so as to load the order guidance page based on the page view data on the pushed session terminal, and guide the confirmation of the electronic transaction order based on the content of the guidance page. This application's embodiments identify transaction intent documents communicated between buyers and sellers, and use a multimodal recognition model capable of parsing various modal data to parse these documents. An order guidance page is then generated and sent to the buyer to guide them in placing an order. This approach fully utilizes and mines the transaction intent documents, reducing the probability of human error compared to traditional solutions and improving order placement efficiency. It significantly shortens the path from communication to order placement. Particularly effective for B2B scenarios with lengthy communication processes, abundant contextual information, and complex order content, as well as for cross-border scenarios with complex semantic understanding due to multilingual, multi-currency, and transaction terminology environments, the multimodal recognition model can obtain accurate and efficient parsing results. This can encourage more offline consensus-building transactions to flow back to the platform, enhancing platform transaction stickiness and traffic.

[0011] Upon detecting a newly submitted session message carrying a file, a file message event is dispatched. The file message event is pushed to the file processing module via the message middleware. The file processing model then calls the multimodal recognition model to parse the file. The session thread is released immediately after the event is published, without waiting for parsing to complete, ensuring real-time interaction. This enables asynchronous execution of sessions and file processing. Furthermore, it supports dynamically increasing processing capacity to quickly process files when the number of file parsings increases rapidly, improving the elasticity of processing capacity deployment. In the event of a failure in the file processing service, file message events can be accumulated in the message queue of the message middleware, preventing service congestion from affecting file processing.

[0012] The key fields obtained after parsing the transaction intention document can be encapsulated into structured data and mapped and bound to relevant IDs. This not only facilitates subsequent processing but also allows the data to be stored as relevant knowledge or used to further optimize the multimodal recognition model, thereby enhancing the accuracy of result recognition.

[0013] The order guidance page can identify and prompt differences between key fields in the current transaction intent document and historical order guidance pages, differences in content before and after modifications, and / or missing or inconsistent required fields. It can also dynamically track and visually prompt changes to transaction terms, thereby speeding up the browsing and confirmation of the order guidance page, improving order conversion efficiency, and shortening the order confirmation path.

[0014] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application, it can be implemented according to the contents of the specification. In order to make the above and other objects, features and advantages of this application more obvious and understandable, specific embodiments of this application are given below. Attached Figure Description

[0015] In the accompanying drawings, unless otherwise specified, the same reference numerals throughout the various drawings denote the same or similar parts or elements. These drawings are not necessarily drawn to scale. It should be understood that these drawings depict only some embodiments according to this application and should not be construed as limiting the scope of this application.

[0016] Figure 1 This document illustrates an example of the interaction between the various terminals in an embodiment of this application. Figure 2 A schematic diagram of a module design in an example embodiment of this application is shown; Figure 3 A flowchart illustrating a method for generating electronic transaction orders provided in an embodiment of this application is shown; Figure 4A flowchart illustrating a method for processing electronic transaction orders provided in an embodiment of this application is shown; Figure 5 This paper shows a structural block diagram of an electronic transaction order generation device provided in an embodiment of this application; Figure 6 This application shows a structural block diagram of an electronic transaction order processing apparatus provided in an embodiment of the present application; and Figure 7 A block diagram of an electronic device used to implement embodiments of this application is shown. Detailed Implementation

[0017] In the following description, only certain exemplary embodiments are briefly described. As those skilled in the art will recognize, the described embodiments can be modified in various ways without departing from the concept or scope of this application. Therefore, the drawings and description are considered to be exemplary in nature and not restrictive.

[0018] To facilitate understanding of the technical solutions of the embodiments of this application, the relevant technologies of the embodiments of this application are described below. The following relevant technologies are optional solutions and can be combined with the technical solutions of the embodiments of this application in any way, and all of them fall within the protection scope of the embodiments of this application.

[0019] This application provides a scheme for generating electronic transaction orders on the server side, and a corresponding scheme for processing electronic transaction orders on the transaction side, to solve one or more problems existing in the current electronic transaction order generation scheme, such as low efficiency, easy error, and low order conversion rate.

[0020] According to the solution of this application embodiment, transaction sessions based on an electronic trading platform are detected to identify session messages carrying files. Specifically, when a participant uploads a file through the session page, the session message containing the file is captured. This can be achieved by capturing the message stream on the instant messaging protocol layer (such as WebSocket) associated with the electronic trading platform in real time to obtain the session message, or by embedding an event capture function in the session page to capture the message sending success event triggered by interaction between the participants in the front-end interface. The original data packet of the message is then captured to obtain the original session message. Further, a predefined message structure can be parsed to identify whether the session message carries a file. For example, the presence of a specific attachment identifier field or an associated file metadata object (usually containing file ID, URL, type, size, etc.) can be checked in the message structure. If these fields exist and are valid, the session message is determined to be a session message carrying a file; otherwise, it is considered a plain text message. Since this application solution subsequently identifies whether the carried file (defined as the target file) is a transaction intent file, and transaction intent files are usually sent by the seller, the focus here is on monitoring session messages sent by the seller.

[0021] In electronic transaction scenarios, the documents exchanged typically involve various forms. For example, a proforma invoice, which the seller prepares and sends to the buyer during the transaction process, is an informal commercial invoice provided by the exporter to the buyer before shipment. It is used to confirm transaction details such as product name, quantity, unit price, total price, and delivery terms. It often serves as proof of a preliminary agreement between the buyer and seller and is widely used in cross-border transactions. Its forms include text modality (language information directly encoded by characters, such as product descriptions and price figures), visual modality (image features such as layout structure, table frames, stamps, logos, and bold fonts that carry semantics), and structural modality (topological relationships between text and visual elements, such as the correspondence between "unit price" and specific values ​​in the same row in a table). Using a single modality for semantic recognition relies on pre-defined, rigid text pattern matching rules. It only analyzes the extracted text and cannot acquire and utilize important modal information such as the original visual layout, table structure, font style, and seal position in the document. It loses crucial visual context and structured logic, leading to information fragmentation and misinterpretation. It cannot handle the free-format documents with diverse formats in reality. For example, it cannot distinguish between page footer text and body clauses, cannot accurately determine the semantic role of text, cannot correctly match the header row and data row of cross-page tables, cannot reconstruct the logical relationship between fields, and has difficulty recognizing legal validity marks such as format-based emphasis or seal confirmation. As a result, it has low accuracy in parsing free-format and diverse commercial documents and poor rule generalization ability.

[0022] In this embodiment of the application, after detecting a session message carrying a file, a multimodal recognition model is invoked to parse the target file carried in the session message, and the parsing result of the target file is used to identify whether the target file is a transaction intention file.

[0023] A transaction intent document refers to various documents used to communicate and confirm commercial details before a transaction is finalized. It outlines the preliminary intentions reached by both parties during the initial communication, such as pricing, quantity, product details, and cooperation terms. Transaction intent documents can take various forms, including pro forma invoices, draft contracts or orders, service proposals / project plans, memorandums of understanding, and letters of intent. Taking a pro forma invoice as an example, a complete pro forma invoice typically contains three main categories of information: basic and identifying information, core transaction details, and supporting and compliance information. Basic and identifying information includes clearly marked "pro forma invoice," a unique invoice number, issuance date, and the full names and addresses of both the buyer and seller. Core transaction details include detailed product names and specifications, quantity, unit price, total amount, price terms, shipment period, mode of transport, payment terms, and the seller's bank information. Supporting and compliance information is particularly important in international trade and may include commodity codes for customs declaration, currency type, general terms of trade, discount information, and often includes disclaimers such as "This invoice is not intended for accounting or deduction purposes." These contents together form an informal business document used for quoting prices, applying for import licenses, and as the basis for subsequent transactions.

[0024] The target file is input into the multimodal recognition model to obtain the key fields of the file output by the model, such as product name, unit price, quantity, total amount, payment method, delivery date, and transaction terms. The multimodal recognition model is a machine learning model capable of parallel processing and deep fusion of information from multiple modalities. It is typically based on cross-modal attention mechanisms and joint representation learning. By fusing and understanding data from various modalities, such as text, images, tables, and structured / unstructured data, it correlates them within a unified semantic space, achieving comprehensive information perception, semantic understanding, and intelligent reasoning capabilities.

[0025] To enable accurate identification of target documents, the basic model needs to be iteratively trained using a large number of samples labeled with field positions and types (such as product name and total price). This allows the multimodal recognition model to learn and internalize the complex mapping relationships between visual features, text content, and business semantics in the document, thereby significantly improving its accuracy and generalization ability in extracting structured information from target documents. The multimodal recognition model in this application is used to identify transaction intent documents. In B2B cross-border transaction scenarios, to enable the multimodal recognition model to accurately parse diverse global transaction intent documents, it can be trained using a set of labeled samples covering multiple languages, currencies, and common format templates from multiple countries. Each sample in the set is labeled with the visual position of key fields, business type, and cross-border transaction terms. Through iterative learning of these samples, the model can not only establish a universal mapping between text, layout, and semantics, but also internalize the subtle differences in field descriptions, terminology usage, and layout conventions in business documents from different regions, thereby achieving highly robust structured information extraction for various cross-border transaction intent documents.

[0026] During parsing, the multimodal recognition model extracts and outputs standardized data structures through its complex internal network computation. This includes identifying and classifying key fields (product, quantity, price, logistics, payment terms, etc.) and their values, the logical block affiliation of key fields within the document, and text fragments with type indications such as titles and terms of effect. For example, when processing a pro forma invoice using a multimodal recognition model, it can simultaneously understand the text label "Total Amount" and its adjacent value "USD 5,000.00," as well as their visual alignment within the table, thereby outputting a standardized key-value pair data unit.

[0027] When identifying whether a target document is a transaction intent document based on the parsing results, the multimodal recognition model is used to determine if the document's key fields include those that match the target key fields. If the key fields do match, the document is considered a transaction intent document. For example, this involves identifying whether key fields include product name, quantity, unit price, shipping method, transaction terms, freight, delivery date, order prepayment, and final payment. Besides key field analysis, the document can also assess the clarity of its commercial intent, whether field combinations and terms express a clear offer or confirmation, and whether its format and fixed wording conform to commercial document conventions. Weighted scoring is applied to each dimension; when the overall confidence level exceeds a preset threshold, the document is determined to be a transaction intent document, thus achieving accurate and interpretable identification of the document's commercial attributes. If identified as a non-transaction intent document, it is marked for manual review and added to the pending queue. The parsing results are checked in parallel to ensure they meet the requirements of the preset dimensions.

[0028] When the target file is a transaction intent file, the page view data for the order onboarding page is generated based on the parsing results of the target file. This page view data serves as the foundation for loading the order onboarding page, forming the front-end page code document for dynamic rendering. It is used to generate a pre-populated, modifiable order onboarding interface with intelligent guidance prompts. The page view data contains key order data that needs to be displayed on the page, and also explicitly specifies the data's position, grouping, and sorting on the interface. It also includes the types of interactive controls (such as input boxes and dropdown menus). The page view data can be in JSON or a specific protocol format.

[0029] Before generating page view data, you can first send an overview of the order guidance page (such as an order card, including core elements such as product name, quantity, unit price, and payment method) to the transaction participants, and provide them with the option to choose whether to continue pushing the transaction guidance page. After obtaining the transaction participants' confirmation to push the transaction guidance page, you can then generate the page view data.

[0030] Once the target file is identified as a transaction intent document and page view data is generated, the page view data can be pushed to at least one session endpoint participating in the transaction session, i.e., the seller's and / or buyer's session endpoint. The session endpoint receiving the page view data can load an order guidance page based on the page view data, thus enabling content-guided confirmation of the electronic transaction order. The order guidance page loaded based on the page view data not only intuitively displays the pre-filled order details converted from the transaction intent document, but also proactively guides the user through the entire process from review and fine-tuning to final submission through embedded structured operation guidance. This transforms static transaction information into a dynamic interactive task that drives the user to perform a confirmation operation, achieving efficient and error-free conversion of commercial intent into a formal order on the platform. The order can be a regular order or a formal order created by the platform and protected by the platform's credit guarantee service, offering advantages such as fund security, performance guarantee, and dispute resolution. The order guidance page and order confirmation method balance efficiency and accuracy.

[0031] This application's embodiments identify transaction intent documents during communication between buyers and sellers, and use a multimodal recognition model capable of parsing various modal data to parse these documents, generating an order guidance page that is sent to the buyer to guide them in placing an order. This approach fully mines and utilizes the transaction intent documents, reducing the probability of human error compared to traditional solutions, improving order placement efficiency, significantly shortening the path from communication to order placement, and enhancing transaction conversion efficiency. Especially in B2B scenarios with lengthy communication processes, abundant contextual information, and complex order content, and even in cross-border scenarios with complex semantic understanding due to multilingual, multi-currency, and transaction terminology environments, this solution maintains high accuracy, effectively guiding more offline transactions back to the online platform, thereby strengthening the platform's transaction stickiness, data asset accumulation, and business ecosystem vitality.

[0032] When retrieving session messages carrying files sent in a transaction session, newly submitted session messages can be obtained and identified as carrying files. When the multimodal recognition model is invoked to parse the target file carried in the session message, event distribution can be performed through message middleware to drive file parsing. Specifically, when a transaction participant sends a session message carrying a file in the instant messaging session window associated with the transaction platform, and the newly submitted session message carrying a file is identified, file message event distribution is triggered. The file message event is pushed to the file processing module dedicated to processing transaction intention files through the message middleware. The file processing module, upon receiving the pushed file message event, drives the multimodal recognition model to parse the target file carried in the session message. The session thread is released immediately after publishing the event, without waiting for parsing to complete, ensuring real-time interaction. This allows asynchronous execution of session and file processing, and supports dynamic increases in processing capacity to quickly process files even with a rapid increase in the number of files parsed, improving the elasticity of processing capacity deployment. In the event of a failure in the file processing service, file message events can be accumulated in the message middleware's message queue, preventing service congestion from affecting file processing.

[0033] To reduce resource waste, before calling the multimodal recognition model to parse the target file carried in the session message, a preliminary identification of the target file can be performed based on its file attributes. This involves extracting the file attributes of the target file and determining whether these attributes match those of the transaction intent file. File attributes can include file links, sizes, file types, etc. Simple judgments can initially filter out files that do not match the attributes of the transaction intent file. For example, if the transaction intent file is a PDF, Word, or Excel file, and the file carried in the session message is in JPG format, it is not a transaction intent file requiring further identification and can be filtered out without proceeding to the next step.

[0034] To improve the accuracy and reliability of model recognition and understanding, the target file can be preprocessed before calling the multimodal recognition model to parse the target file carried in the session message. This preprocessing can include at least one of the following: denoising, skew correction, and table line detection. Specifically, denoising aims to eliminate background blemishes, irrelevant watermarks, and broken strokes generated during scanning or transmission, ensuring the clarity of text and graphics. Skew correction uses geometric transformations to rotate the document image to a standard horizontal position, restoring the proper spatial relationships between characters and rows / columns, providing a geometric basis for subsequent layout analysis and OCR. Table line detection targets the core structure of commercial documents, enhancing or completing the visual continuity of table borders to help the model understand the logical relationships between cells; other preprocessing operations can also be introduced. Preprocessing effectively reduces various noises in the original file, allowing the multimodal recognition model to focus more on extracting the clean semantic information inherent in the document, improving the accuracy of subsequent structured field extraction.

[0035] The key fields of the output files from the multimodal recognition model can be encapsulated into PI structured data in JSON format and further stored in a database to construct a structured data asset for the transaction intention file. This asset is then linked to the session and information of both parties involved, such as establishing mapping relationships with buyer IDs, seller IDs, and session IDs. This facilitates subsequent data retrieval and querying based on IDs, and can be used for intelligent pricing, risk assessment, supply chain finance, and other applications. Furthermore, it can be used to construct training samples for the multimodal recognition model, thereby further enhancing the accuracy of the results. Simultaneously, operation logs can be recorded, making the transaction process traceable.

[0036] When generating page view data for the order guidance page based on the parsing results of the target file, the key fields of the file output by the multimodal recognition model can be obtained, and page view data can be generated based on these key fields. Specifically, the generation method for page view data can be differentiated based on whether a corresponding historical order guidance page exists for this transaction. Each order guidance page is saved after generation, and transaction participants can view or modify it. If the page is closed without placing an order, it will be displayed again upon reopening, showing previously displayed historical transaction guidance pages. Simultaneously, the historical transaction guidance pages are updated based on the key fields generated corresponding to the new session message. In detail, before generating the order guidance page, it checks whether a corresponding historical order guidance page exists for this session. If a historical order guidance page exists, the page view data for the new order guidance page is generated based on the key fields and the historical order guidance page. If no historical order guidance page exists, the page view data for the order guidance page is generated based on the key fields and the guidance page template.

[0037] When generating page view data for a new order guidance page based on key fields in the file and historical order guidance pages, the differences between the key fields in the file and the page content of the historical order guidance pages can be identified and recorded as the first difference content. Furthermore, the page view data of the historical order guidance pages can be updated based on the first difference content, and a highlighting rendering effect can be configured for the first difference content in the modified page view data, such as highlighting the difference content.

[0038] You can also compare key fields in the document with multiple required fields (shipping method, shipping date) and / or preset fields (such as preset shipping methods) on the order guide page. If at least one required field is missing from the key field in the document or is inconsistent with the preset field, you can configure a highlighting effect, such as bolding, for the missing or inconsistent field in the page view data of the order guide page. For example, if the trading platform has preset values ​​for some key fields, such as shipping methods including sea freight, land freight, air freight, and express delivery, and the value of the key field in the document is inconsistent with the above options, it means that it does not match the preset, and special display effects need to be set to prompt the buyer to modify and confirm.

[0039] If a participant in the session modifies the order guidance page, the system can also obtain the modification operation submitted by the session client based on the order guidance page, update the page view data based on the modification operation, identify the differences between the updated page view data and the original transaction intention document, and record them as the second difference content. The system can then configure a highlighting rendering effect for the second difference content in the updated page view data, such as highlighting.

[0040] The highlighted rendering effects can target key terms or fields in the order onboarding page. By identifying and highlighting differences between the key fields of the current transaction intent document and historical order onboarding pages, differences in content before and after modifications, and / or missing required fields and / or inconsistent content, the system can dynamically track and visually prompt changes to transaction terms. This facilitates faster browsing and confirmation of the order onboarding page, improves order conversion efficiency, and shortens the order confirmation path.

[0041] In addition to configuring highlighted rendering effects, corresponding explanatory notes can be added to key terms or fields in the page view data. For example, a term named "Logistics Terms Highlighted Field" could be marked with the explanation: "Users can agree on a fixed delivery time, or delivery can be made N days after the initial and final payments." For cases where the deposit amount is too low, the explanation could be: "T / T 30% deposit recommended." For cases where quality inspection clauses are missing, the explanation could be: "It is recommended to add quality inspection clauses." For cases where the delivery date is within the set date range, the explanation could be: "The delivery date is earlier than the current date and needs adjustment." These explanations can be generated by calling a model, which can be trained based on pre-collected problem data and sample data for the explanations. The explanations provide specific modification suggestions, which can speed up order confirmation.

[0042] The system retrieves the order confirmation submitted on the order guidance page, generates a corresponding electronic transaction order, and verifies the completeness of required fields, consistency of amount, and compliance of payment methods after order confirmation. Upon passing all pre-verification checks, the transaction system calls the order generation service to create an order conforming to platform specifications and initializes its status to "pending payment." Simultaneously, the structured data from the original transaction intent document is bound as an attachment. The system calculates and returns the order result (including a unique order number, an immediately available payment link, and an estimated fulfillment timeline). The buyer's end dynamically renders the order page based on this information and clearly notifies the buyer that the transaction intent document has been synchronized to the order details. The buyer can then view the order and make payment. Through the above process of recognizing the session message carrying the document, displaying the order guidance document, confirming the order, and making the order payment, the system completes the entire process from perception to reasoning to suggestion to execution, allowing buyers to easily complete order placement and payment through simple interaction. The complete order record can also be persistently associated with all contexts in the entire transaction assistance process (including the complete operation log of the transaction guidance page generated above, the historical transaction guidance pages with added highlight effects, and the buyer's modification trajectory), thereby forming a full-link data archive that can be used for post-event auditing, dispute resolution, and continuous optimization of algorithm models.

[0043] Accordingly, during the electronic transaction order processing on the buyer's end, the process first receives a session message carrying a file sent by the seller in the transaction session. Then, it receives the page view data of the order guidance page, loads the order guidance page based on the page view data, and guides the buyer to confirm the electronic transaction order based on the content of the order guidance page. The page view data is generated based on the parsing results of the target file carried in the session message. The page view data is generated when the target file is identified as a transaction intent document based on the parsing results. The target file is parsed using a multimodal recognition model. After displaying the transaction guidance page, it can also receive modification operations submitted based on the order guidance page, obtain the updated page view data based on the modification operations, and reload the order guidance page based on the updated page view data. A highlighted rendering effect is configured for the second difference between the updated page view data and the transaction intent document. After displaying the transaction guidance page, it can also receive order confirmation operations submitted on the order guidance page, obtain the corresponding electronic transaction order, and load the page corresponding to the electronic transaction order. The process executed on the buyer's end corresponds to the process executed on the server side, and similar content will not be elaborated here.

[0044] The aforementioned client receives a conversation message with attachments from the seller. The corresponding session server (communication backend) forwards the message event to the transaction backend to execute a series of processes, including file recognition and order view data generation. Subsequently, the transaction backend generates a card component summarizing the order guidance page and pushes it to the client via the session server. When the buyer clicks to view and selects to generate the transaction guidance page on the client, the request is passed to the transaction frontend. The transaction frontend triggers the generation of page view data. After the transaction backend generates the page view data, it is pushed to the transaction frontend, triggering the display of the card component on the client. After selecting to view the card component, the buyer is redirected from the client to the transaction frontend to display the order guidance page. Subsequent modifications to the order guidance page are passed from the transaction frontend to the transaction backend, and after the transaction backend generates an updated order guidance page, it is passed to the transaction frontend for display.

[0045] The above-mentioned step of pushing page view data to at least one session end participating in the transaction session is to push a card component that jumps to the page view data. After the buyer clicks on the card component, the transaction front end is called to load the transaction guidance page based on the page view data.

[0046] Figure 1This illustration shows an example of the interaction between various terminals in an embodiment of this application. The customers are the buyer and seller; the communication front-end is the session window; the transaction front-end is the page of the transaction platform; the communication back-end is the session server corresponding to the session window; the transaction back-end is the transaction server corresponding to the transaction platform; and the algorithm carries a multimodal recognition model. The overall interaction process can be divided into four stages: PI file reception and intelligent recognition, order card push and order guidance, buyer editing and intelligent verification, and order submission.

[0047] Phase 1: PI File Reception and Intelligent Recognition When a seller sends a Proforma Invoice (PI) file attachment in a transaction session, a file message event is automatically triggered. The backend message middleware pushes this event to the "PI Recognition Service," logs it, and notifies the transaction backend to prepare to receive data. The transaction backend receives the message and performs PI file recognition. The recognition service activates its AI recognition engine, a multimodal recognition model. First, it preprocesses the PI file image, performing noise reduction and tilt correction. Then, it uses the multimodal recognition model to identify key fields such as product, price, and transaction terms. Further, it determines whether the file is a valid PI based on the completeness of these key fields. If the file is not identified as a PI, it is marked as "requiring manual review." If it is a PI, structured PI data is generated and stored. This structured data is then associated with the buyer, seller, and session ID and stored in the database, triggering a PI order recognition event. The transaction backend subscribes to this PI order recognition event.

[0048] Phase Two: Order Guide Page Display Upon receiving a PI order recognition event, the transaction backend sends an order card (i.e., an overview of the order guidance page). This order card is forwarded from the transaction backend to the communication frontend for display. After viewing the card, if the user selects to click "Draft Order Guidance Page," the communication frontend expands the card component (Copilot) of the order guidance page and queries the page view data of the order guidance page from the transaction backend, triggering the generation of the page view data. During this generation process, the transaction backend queries the key fields of the PI file and historical editing records, specifically querying the Copilot records to extract the draft record of the order guidance page. The transaction backend determines whether a historical record of the order guidance page exists: if not, it directly generates a preliminary draft of the order guidance page view based on the PI data; if so, it loads the last edited historical order guidance page and calculates and highlights the changes between the current PI and the historical order guidance page. This data is aggregated to generate complete page view data, including a product list, price terms, and a smart prompt area for the order guidance page (such as prompts for missing required fields). The communication front end displays the Copilot card component based on the buyer's request to view Copilot. Clicking the card component will further redirect the buyer to the transaction front end to display the order guidance page.

[0049] Phase Three: Buyer Editing and Intelligent Verification Buyers can directly modify order fields on the order onboarding page. Each modification triggers a closed-loop process in real time: the transaction frontend updates the draft content, updates the timestamp on the order onboarding page, recalculates the highlighted differences, and re-aggregates the order view. The "dynamic highlighted differences" visually highlight any changes by continuously comparing the current order onboarding page with the original PI data. Simultaneously, suggestions (such as recommended payment methods) are refreshed in real time based on the latest modifications, providing intelligent guidance throughout the editing process. The draft record and Copilot record are updated simultaneously with the order onboarding page update.

[0050] Phase Four: Order Submission and Persistence After confirming the information, the buyer submits the order, initiating the order placement request through the transaction frontend displaying the order guidance page. The transaction backend performs multiple checks on the incoming request, including the completeness of required fields and the consistency of the amount. Upon successful verification, the service is invoked to create the order, setting its status to "Pending Payment," and binding the original PI structured data as an attachment. Subsequently, an order number, payment link, and other information are generated, and the frontend displays a "Order Successful" page indicating that the PI content has been synchronized. Finally, the system persistently associates all process data, including the final order, operation logs, highlighted history, and user modification history, forming a complete data chain for auditing, optimization, and traceability.

[0051] Figure 2 A schematic diagram of a module design in an example of an embodiment of this application is shown. The processing device corresponding to the overall solution is divided into three main modules.

[0052] Module 1: Communication Message Processing and Order Card Sending Module This module serves as the input and trigger entry point, responsible for real-time monitoring and processing of the message flow in the transaction session. It captures PI file attachments sent by the seller and parses message metadata (such as attachment links, types, and sizes) using components like AtmMessageConsumer (message consumption), identifying files requiring multimodal recognition. Upon confirmation, the module proactively pushes an "order draft card" (a draft of the order guidance page) to the buyer's session interface via services like SendMessageCard (message card sending). The card displays key fields such as product and amount, guiding the conversion from communication event to transaction guidance.

[0053] Module 2: PI Algorithm Recognition and Copilot Order Recording Module The AITradeService calls a multimodal recognition model to perform joint analysis on the text, tables, and images in the PI file, extracting key fields such as product, price, logistics, and payment terms. The data is then structured using PiStructureAdaptor and stored in PiStructureData via PiStructureWriteService. Buyer data is also retrieved from BuyerTaPost and stored in PiStructureData. The process involves invoking the TradeCopilotViewController to initiate view generation, and then invoking the TradeCopilotService to generate interactive order guidance page view data based on the PI structured data. This data is automatically compared against preset rules, highlighting controversial clauses (such as mismatched transaction terms) that require special attention. Specifically, the process involves retrieving persistently stored Pi data from PiStructureData via PiStructureQueryService, retrieving historically generated order guidance pages from TradeCopilotRecord via TradeCopilotRecordQueryService, and generating a complete TradeCopilotRecord (operation log) via TradeCopilotRecordWriteService. This provides a structured data foundation and end-to-end audit basis for the entire decision-making process.

[0054] Module 3: Order View and Order Placement Module This module is responsible for converting the recognition results of the multimodal recognition model into a final, submitable order. Buyers access the order draft on the front end through an interface such as ContractRestController (order controller). TradeCreateViewOpenService loads the corresponding structured PI data and page view data from historical transaction guidance pages, dynamically rendering them into a visual and editable form view. This process implements a hybrid intelligent mode of AI-generated initial draft + human confirmation; that is, AI provides a pre-filled initial draft, which buyers can then confirm or modify. When the user submits, TradeCreateService handles the complete order creation, validation, and persistence (stored in the Draft / Trade database) logic, and connects to subsequent payment and fulfillment processes, thus completing a closed loop from intelligent parsing to transaction completion.

[0055] The following is an example data model design from an embodiment of this application, defining the core data objects and their relationships that support the entire processing flow, focusing on enabling AI to understand business intent and allowing the system to support flexible negotiation. It should be noted that the model described here refers to the object model definition in a Java system, where each model contains corresponding designed fields and methods.

[0056] The PI structured model (StructurePojo) is the system's data source, carrying key fields such as product, logistics, funds, and transaction terms from the PI file. To accurately support the complexity of cross-border B2B transactions, its fields adopt a fine-grained object-oriented design, including independent sub-objects such as shipmentFee, tradeTerm, and payment, thus natively supporting the flexible combination and precise expression of multiple currencies, multiple modes of transportation, and multiple payment terms at the data structure level.

[0057] In the order terms highlighting model, key terms recognized by AI (such as "FOB Shanghai" and "30% prepayment") are encapsulated as TradeTermHighlight objects, which include highlightTerm (term name), highlightList (specific highlighted fields), and termDescription (explanation). For example, the term name is: logistics terms highlighted field; the delivery time explanation is: users can agree on a fixed delivery time, or they can deliver N days after the initial and final payments.

[0058] A clause can contain multiple fields. For example, a logistics clause includes the mode of transport and delivery time. A logical reason is set for each field. Each highlighted field is further broken down into a Highlight object, which records the field, data, and reason (e.g., because the unit price is higher than the historical price, it is recommended to confirm). Contextual explanations can also be provided. For example, if the PI file identifies that the current delivery date is earlier than the current date, the delivery date will be highlighted and an explanation will be given: "The delivery date is earlier than the current date, and adjustment is required."

[0059] The transaction negotiation model aims to structurally record and manage the modification process of terms, including TradeTermNegotiation and its detailed NegotiationDetail. The model records key node information such as originValue, newValue, buyerAppeal, and sellerPlan, and manages it through built-in status fields (such as "Pending Confirmation" and "Accepted") and state machine logic. This ensures that the entire business negotiation process is fully traceable, auditable, and supports flexible online negotiation processes.

[0060] The boundary view model is an aggregated data carrier for front-end interaction, namely the TradeCopilotView (Trading Intelligent Assistant View) class, designed specifically for efficient front-end UI rendering. Its core fields include tradeViewUltronData (raw transaction data snapshot) and tradeTermHighlightList (aggregated list of highlighted terms). This model provides formatted data for the front-end, facilitating the dynamic rendering of an intelligent guided view that integrates "AI hints" and "negotiation entry points," effectively isolating complex back-end logic from the front-end display.

[0061] The execution entity in this application embodiment can be an application, service, instance, functional module in software form, virtual machine (VM), container, or cloud server, or hardware device with data processing function (such as server or terminal device) or hardware chip (such as CPU, GPU, FPGA, NPU, AI accelerator card, or DPU). The device for providing the service can be deployed on the computing device of the application providing the corresponding service or on a cloud computing platform providing computing power, storage, and network resources. The cloud computing platform can provide services in the following modes: IaaS (Infrastructure as a Service), PaaS (Platform as a Service), SaaS (Software as a Service), or DaaS (Data as a Service). Taking the platform providing SaaS (Software as a Service) as an example, the cloud computing platform can utilize its own computing resources to provide related model training, model-based prediction, and partial or complete implementation of solution processes. The specific application architecture can be built according to service requirements.

[0062] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0063] The technical solution of this application and how it solves the aforementioned technical problems are described in detail below with specific embodiments. The listed specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0064] This application provides a method for generating electronic transaction orders, such as... Figure 3 The diagram shows a flowchart of an electronic transaction order generation method 300 according to an embodiment of this application. Method 300 may include: In step 301, a session message carrying a file sent in the transaction session is obtained; in step 302, a multimodal recognition model is invoked to parse the target file carried in the session message, and the parsing result of the target file is used to identify whether the target file is a transaction intention file; in step 303, if the target file is a transaction intention file, page view data for an order guidance page is generated based on the parsing result of the target file; in step 304, the page view data is pushed to at least one session terminal participating in the transaction session, so that the order guidance page is loaded on the pushed session terminal based on the page view data, and the electronic transaction order is guided to be confirmed based on the content of the guidance page.

[0065] In one embodiment, obtaining the session message carrying a file sent in the transaction session includes: obtaining a newly submitted session message and identifying that the newly submitted session message carries a file; the step of calling the multimodal recognition model to parse the target file carried by the session message includes: triggering file message event distribution, pushing the file message event to a file processing module dedicated to processing transaction intention files through a message middleware; and calling the file processing module, after obtaining the pushed file message event, driving the multimodal recognition model to parse the target file carried by the session message.

[0066] In one embodiment, before invoking the multimodal recognition model to parse the target file carried by the session message, the method further includes: identifying the file attributes of the target file and determining that the file attributes of the target file match the file attributes of the transaction intention file.

[0067] In one embodiment, before invoking the multimodal recognition model to parse the target file carried by the session message, the method further includes performing at least one operation on the target file: denoising, tilt correction, and table line detection.

[0068] In one embodiment, the step of calling the multimodal recognition model to parse the target file carried in the session message includes: inputting the target file into the multimodal recognition model to obtain the file key fields output by the multimodal recognition model.

[0069] In one embodiment, the method further includes: parsing the target file key fields obtained by the multimodal recognition model into structured data, and establishing a mapping relationship between the structured data and the IDs of both parties in the session and the session ID.

[0070] In one embodiment, identifying whether the target file is a transaction intent file based on the parsing result of the target file includes: determining whether the file key fields output by the multimodal recognition model include fields that match the target key fields of the transaction intent file; if the file key fields include fields that match the target key fields, then the target file is determined to be a transaction intent file.

[0071] In one embodiment, generating page view data for the order guidance page based on the parsing result of the target file includes: obtaining the file key fields output by the multimodal recognition model, and generating page view data based on the file key fields.

[0072] In one embodiment, generating page view data based on the file key fields includes: checking whether a historical order guidance page corresponding to the current session already exists; if a historical order guidance page exists, generating page view data for a new order guidance page based on the file key fields and the historical order guidance page; if no historical order guidance page exists, generating page view data for an order guidance page based on the file key fields and the guidance page template.

[0073] In one embodiment, generating page view data for a new order guidance page based on the file key fields and the historical order guidance page includes: identifying a first difference between the file key fields and the page content of the historical order guidance page; updating the page view data of the historical order guidance page based on the first difference, and configuring a highlighting rendering effect for the first difference in the modified page view data.

[0074] In one embodiment, generating page view data based on the file key fields further includes: comparing the file key fields with multiple required fields and / or preset content of the order guidance page; if the file key fields are missing at least one required field and / or inconsistent with the preset content, configuring a highlighting rendering effect for the missing required field and / or inconsistent content in the page view data of the order guidance page.

[0075] In one embodiment, the method further includes: obtaining a modification operation submitted by the session client based on the order guidance page, and updating the page view data based on the modification operation; identifying a second difference between the updated page view data and the transaction intent document, and configuring a highlighting rendering effect for the second difference in the updated page view data.

[0076] In one embodiment, the highlighted rendering effect is configured while corresponding explanatory prompts are added to the page view data.

[0077] In one embodiment, the method further includes: obtaining the order confirmation operation submitted on the order guidance page and generating a corresponding electronic transaction order.

[0078] According to the embodiments of this application, a session message carrying a file sent in a transaction session is obtained; a multimodal recognition model is called to parse the target file carried in the session message; and the parsing result of the target file is used to identify whether the target file is a transaction intention file. If the target file is a transaction intention file, page view data for an order guidance page is generated based on the parsing result of the target file. The page view data is pushed to at least one session terminal participating in the transaction session so as to load the order guidance page based on the page view data on the pushed session terminal, and guide the confirmation of the electronic transaction order based on the content of the guidance page. This application's embodiments identify transaction intent documents communicated between buyers and sellers, and use a multimodal recognition model capable of parsing various modal data to parse these documents. An order guidance page is then generated and sent to the buyer to guide them in placing an order. This approach fully utilizes and mines the transaction intent documents, reducing the probability of human error compared to traditional solutions and improving order placement efficiency. It significantly shortens the path from communication to order placement. Particularly effective for B2B scenarios with lengthy communication processes, abundant contextual information, and complex order content, as well as for cross-border scenarios with complex semantic understanding due to multilingual, multi-currency, and transaction terminology environments, the multimodal recognition model can obtain accurate and efficient parsing results. This can encourage more offline consensus-building transactions to flow back to the platform, enhancing platform transaction stickiness and traffic.

[0079] Upon detecting a newly submitted session message carrying a file, a file message event is dispatched. The file message event is pushed to the file processing module via the message middleware. The file processing model then calls the multimodal recognition model to parse the file. The session thread is released immediately after the event is published, without waiting for parsing to complete, ensuring real-time interaction. This enables asynchronous execution of sessions and file processing. Furthermore, it supports dynamically increasing processing capacity to quickly process files when the number of file parsings increases rapidly, improving the elasticity of processing capacity deployment. In the event of a failure in the file processing service, file message events can be accumulated in the message queue of the message middleware, preventing service congestion from affecting file processing.

[0080] The key fields obtained after parsing the transaction intention document can be encapsulated into structured data and mapped and bound to relevant IDs. This not only facilitates subsequent processing but also allows the data to be stored as relevant knowledge or used to further optimize the multimodal recognition model, thereby enhancing the accuracy of result recognition.

[0081] The order guidance page can identify and prompt differences between key fields in the current transaction intent document and historical order guidance pages, differences in content before and after modifications, and / or missing or inconsistent required fields. It can also dynamically track and visually prompt changes to transaction terms, thereby speeding up the browsing and confirmation of the order guidance page, improving order conversion efficiency, and shortening the order confirmation path.

[0082] This application provides a method for processing electronic transaction orders, such as... Figure 4 The diagram shows a flowchart of an electronic transaction order processing method 400 according to an embodiment of this application. The method 400 may include: In step 401, a session message carrying a file sent by the seller in the transaction session is received; in step 402, page view data of the order guidance page is received, the page view data is generated based on the parsing result of the target file carried in the session message, the page view data is generated when the target file is identified as a transaction intention file according to the parsing result of the target file, the target file is parsed by calling a multimodal recognition model; in step 403, the order guidance page is loaded based on the page view data, and the electronic transaction order is guided to be confirmed based on the content of the order guidance page.

[0083] In one embodiment, the method further includes: receiving a modification operation submitted based on the order guidance page, obtaining page view data updated based on the modification operation, and reloading the order guidance page based on the updated page view data; wherein, a highlighting rendering effect is configured for the second difference between the updated page view data and the transaction intent document.

[0084] In one embodiment, the method further includes: receiving an order confirmation operation submitted on the order guidance page, obtaining the corresponding electronic transaction order, and loading the page corresponding to the electronic transaction order.

[0085] Corresponding to the examples and method embodiments provided in this application, this application also provides an apparatus for generating electronic transaction orders. For example... Figure 5The diagram shows a structural block diagram of an electronic transaction order generation device 500 according to an embodiment of this application. The device 500 may include: a session message acquisition module 501, used to acquire session messages carrying files sent in a transaction session; a file parsing module 502, used to call a multimodal recognition model to parse the target file carried in the session message; an intention file recognition module 503, used to identify whether the target file is a transaction intention file based on the parsing result of the target file; a view data generation module 504, used to generate page view data of an order guidance page based on the parsing result of the target file when the target file is a transaction intention file; and a view data push module 505, used to push the page view data to at least one session terminal participating in the transaction session, so as to load the order guidance page on the pushed session terminal based on the page view data, and guide the confirmation of the electronic transaction order based on the content of the guidance page.

[0086] In one embodiment, the session message acquisition module is specifically used to acquire newly submitted session messages and identify that the newly submitted session messages carry files; the file parsing module includes: an event distribution submodule, used to trigger file message event distribution, and push the file message event to a file processing module dedicated to processing transaction intention files through a message middleware; and an event consumption submodule, used to call the file processing module, and after obtaining the pushed file message event, drive a multimodal recognition model to parse the target file carried in the session message.

[0087] In one embodiment, the apparatus further includes: an attribute matching and identification module, configured to identify the file attributes of the target file and determine that the file attributes of the target file match the file attributes of the transaction intention file before the multimodal identification model is invoked to parse the target file carried by the session message.

[0088] In one embodiment, the apparatus further includes: the method further includes: a preprocessing module, configured to perform at least one of the following operations on the target file: denoising, tilt correction, and table line detection, before the multimodal recognition model is invoked to parse the target file carried by the session message.

[0089] In one embodiment, the file parsing module is specifically used to input the target file into the multimodal recognition model to obtain the file key fields output by the multimodal recognition model.

[0090] In one embodiment, the apparatus further includes: a data encapsulation module, used to encapsulate the file key fields obtained by the multimodal recognition model from parsing the target file into structured data, and to establish a mapping relationship between the structured data and the IDs of both parties in the session and the session ID.

[0091] In one embodiment, the intent document recognition module is used to determine that the target document is a transaction intent document based on whether the key fields of the document output by the multimodal recognition model include fields that match the target key fields of the transaction intent document. If the key fields of the document include fields that match the target key fields, then the target document is a transaction intent document.

[0092] In one embodiment, the view data generation module includes: a field acquisition submodule for acquiring key file fields output by the multimodal recognition model, and a view data generation submodule for generating page view data based on the key file fields.

[0093] In one embodiment, the data generation submodule includes: a historical page search subunit, used to search whether a historical order guidance page corresponding to the current session already exists; a first data generation subunit, used to generate page view data of a new order guidance page based on the file key fields and the historical order guidance page if a historical order guidance page exists; and a second data generation subunit, used to generate page view data of an order guidance page based on the file key fields and the guidance page template if a historical order guidance page does not exist.

[0094] In one embodiment, the first data generation subunit is specifically used to identify the first difference between the key fields of the file and the page content of the historical order guidance page; update the page view data of the historical order guidance page according to the first difference, and configure a highlighting rendering effect for the first difference in the modified page view data.

[0095] In one embodiment, the view data generation module further includes a mandatory field comparison submodule, used to compare the key fields of the document with multiple mandatory fields and / or preset content of the order guidance page. If the key fields of the document are missing at least one mandatory field and / or inconsistent with the preset content, the module configures a highlighting rendering effect for the missing mandatory field and / or inconsistent content in the page view data of the order guidance page.

[0096] In one embodiment, the apparatus further includes: a view data modification module, configured to acquire a modification operation submitted by the session client based on the order guidance page, and update the page view data based on the modification operation; and a rendering configuration module, configured to identify a second difference between the updated page view data and the transaction intent document, and configure a highlighting rendering effect for the second difference in the updated page view data.

[0097] In one embodiment, the highlighted rendering effect is configured while corresponding explanatory prompts are added to the page view data.

[0098] In one embodiment, the device further includes a transaction order generation module, used to obtain the order confirmation operation submitted on the order guidance page and generate a corresponding electronic transaction order.

[0099] According to the embodiments of this application, a session message carrying a file sent in a transaction session is obtained; a multimodal recognition model is called to parse the target file carried in the session message; and the parsing result of the target file is used to identify whether the target file is a transaction intention file. If the target file is a transaction intention file, page view data for an order guidance page is generated based on the parsing result of the target file. The page view data is pushed to at least one session terminal participating in the transaction session so as to load the order guidance page based on the page view data on the pushed session terminal, and guide the confirmation of the electronic transaction order based on the content of the guidance page. This application's embodiments identify transaction intent documents communicated between buyers and sellers, and use a multimodal recognition model capable of parsing various modal data to parse these documents. An order guidance page is then generated and sent to the buyer to guide them in placing an order. This approach fully utilizes and mines the transaction intent documents, reducing the probability of human error compared to traditional solutions and improving order placement efficiency. It significantly shortens the path from communication to order placement. Particularly effective for B2B scenarios with lengthy communication processes, abundant contextual information, and complex order content, as well as for cross-border scenarios with complex semantic understanding due to multilingual, multi-currency, and transaction terminology environments, the multimodal recognition model can obtain accurate and efficient parsing results. This can encourage more offline consensus-building transactions to flow back to the platform, enhancing platform transaction stickiness and traffic.

[0100] Upon detecting a newly submitted session message carrying a file, a file message event is dispatched. The file message event is pushed to the file processing module via the message middleware. The file processing model then calls the multimodal recognition model to parse the file. The session thread is released immediately after the event is published, without waiting for parsing to complete, ensuring real-time interaction. This enables asynchronous execution of sessions and file processing. Furthermore, it supports dynamically increasing processing capacity to quickly process files when the number of file parsings increases rapidly, improving the elasticity of processing capacity deployment. In the event of a failure in the file processing service, file message events can be accumulated in the message queue of the message middleware, preventing service congestion from affecting file processing.

[0101] The key fields obtained after parsing the transaction intention document can be encapsulated into structured data and mapped and bound to relevant IDs. This not only facilitates subsequent processing but also allows the data to be stored as relevant knowledge or used to further optimize the multimodal recognition model, thereby enhancing the accuracy of result recognition.

[0102] The order guidance page can identify and prompt differences between key fields in the current transaction intent document and historical order guidance pages, differences in content before and after modifications, and / or missing or inconsistent required fields. It can also dynamically track and visually prompt changes to transaction terms, thereby speeding up the browsing and confirmation of the order guidance page, improving order conversion efficiency, and shortening the order confirmation path.

[0103] Corresponding to the examples and method embodiments provided in this application, this application also provides an electronic transaction order processing apparatus. For example... Figure 6 The diagram shows a structural block diagram of an electronic transaction order processing apparatus 600 according to an embodiment of this application. The apparatus 600 may include: a session message receiving module 601, used to receive a session message carrying a file sent by the seller in a transaction session; a view data receiving module 602, used to receive page view data of an order guidance page, the page view data being generated based on the parsing result of the target file carried in the session message, the page view data being generated when the target file is identified as a transaction intention file based on the parsing result of the target file, the target file being parsed by calling a multimodal recognition model; and a page loading module 603, used to load the order guidance page based on the page view data, so as to guide the confirmation of the electronic transaction order based on the content of the order guidance page.

[0104] In one embodiment, the apparatus further includes: a page update module, configured to receive a modification operation submitted based on the order guidance page, obtain page view data updated based on the modification operation, and reload the order guidance page based on the updated page view data; wherein, a highlighting rendering effect is configured for the second difference between the updated page view data and the transaction intent document.

[0105] In one embodiment, the device further includes an order loading module, configured to receive an order confirmation operation submitted on the order guidance page, obtain the corresponding electronic transaction order, and load the page corresponding to the electronic transaction order.

[0106] The functions of each module in each device in the embodiments of this application can be found in the corresponding description in the above method, and they have corresponding beneficial effects, which will not be repeated here.

[0107] Figure 7 This is a block diagram of an electronic device used to implement embodiments of this application. For example... Figure 7As shown, the electronic device includes a memory 701 and a processor 702. The memory 701 stores a computer program that can run on the processor 702. When the processor 702 executes the computer program, it implements the method described in the above embodiments. The number of memories 701 and processors 702 can be one or more.

[0108] The electronic device also includes: The communication interface 703 is used to communicate with external devices and perform data exchange and transmission.

[0109] If the memory 701, processor 702, and communication interface 703 are implemented independently, they can be interconnected via a bus to communicate with each other. This bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. This bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 7 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0110] Optionally, in a specific implementation, if the memory 701, processor 702, and communication interface 703 are integrated on a single chip, then the memory 701, processor 702, and communication interface 703 can communicate with each other through an internal interface.

[0111] This application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method provided in this application.

[0112] This application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the methods provided in any embodiment of this application.

[0113] This application also provides a chip including a processor for calling and executing instructions stored in a memory, causing a communication device with the chip installed to perform the method provided in this application.

[0114] This application also provides a chip, including: an input interface, an output interface, a processor, and a memory. The input interface, output interface, processor, and memory are connected through an internal connection path. The processor is used to execute code in the memory. When the code is executed, the processor is used to execute the method provided in this application.

[0115] It should be understood that the aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, 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, discrete hardware components, etc. General-purpose processors can be microprocessors or any conventional processor. It is worth noting that the processor can be a processor supporting Advanced Reduced Instruction Set Machines (ARM) architecture.

[0116] Further, optionally, the aforementioned memory may include read-only memory and random access memory. The memory may be volatile memory or non-volatile memory, or may include both. Non-volatile memory may include read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory may include random access memory (RAM), which serves as an external cache. By way of example, but not limitation, many forms of RAM are available. Examples include Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Sync Link DRAM (SLDRAM), and Direct Rambus RAM (DR RAM).

[0117] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions according to this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another.

[0118] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of those different embodiments or examples.

[0119] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "a plurality of" means two or more, unless otherwise explicitly specified.

[0120] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process. Furthermore, the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functionality involved.

[0121] The logic and / or steps described in the flowchart or otherwise herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a processor-included system or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).

[0122] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. All or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware, the program being stored in a computer-readable storage medium, which, when executed, includes one or a combination of the steps of the method embodiments.

[0123] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. This storage medium can be a read-only memory, a disk, or an optical disk, etc.

[0124] The above description is merely an exemplary embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various variations or substitutions within the technical scope described in this application, and these should all be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for generating electronic transaction orders, comprising: Retrieve session messages containing files sent during a transaction session; The multimodal recognition model is invoked to parse the target file carried in the session message, and the parsing result of the target file is used to identify whether the target file is a transaction intention file; If the target file is a transaction intent file, the page view data of the order guidance page is generated based on the parsing result of the target file; The page view data is pushed to at least one session terminal participating in the transaction session, so that an order guidance page is loaded on the pushed session terminal based on the page view data, and the electronic transaction order is guided to be confirmed based on the content of the guidance page.

2. The generation method according to claim 1, wherein, The process of obtaining the session message carrying the file sent in the transaction session includes: Retrieve newly submitted session messages and identify that the newly submitted session messages carry files; The step of calling the multimodal recognition model to parse the target file carried in the session message includes: Trigger file message event distribution, and push the file message event to the file processing module dedicated to processing transaction intention files through message middleware; The file processing module is invoked, and after receiving the pushed file message event, the multimodal recognition model is driven to parse the target file carried in the session message.

3. The generation method according to claim 1, wherein, Before invoking the multimodal recognition model to parse the target file carried in the session message, the method further includes: Identify the file attributes of the target file and determine whether the file attributes of the target file match the file attributes of the transaction intention file.

4. The generation method according to claim 1, wherein, Before invoking the multimodal recognition model to parse the target file carried in the session message, the method further includes: The target file is subjected to at least one of the following operations: denoising, skew correction, and table line detection.

5. The generation method according to claim 1, wherein, The step of calling the multimodal recognition model to parse the target file carried in the session message includes: The target file is input into the multimodal recognition model to obtain the file key fields output by the multimodal recognition model.

6. The generation method according to claim 1, wherein, Also includes: The key fields of the target file obtained by parsing the target file using the multimodal recognition model are encapsulated into structured data, and a mapping relationship is established between the structured data and the IDs of both parties in the session and the session ID.

7. The generation method according to claim 1, wherein, The step of identifying whether the target file is a transaction intention file based on the parsing result of the target file includes: Based on whether the file key fields output by the multimodal recognition model include fields that match the target key fields of the transaction intent file, if the file key fields include fields that match the target key fields, the target file is determined to be a transaction intent file.

8. The generation method according to claim 1, wherein, The page view data for generating the order guidance page based on the parsing results of the target file includes: Obtain the file key fields output by the multimodal recognition model, and generate page view data based on the file key fields.

9. The generation method according to claim 8, wherein, The process of generating page view data based on the key fields of the file includes: Check if a historical order guidance page corresponding to this session already exists; If a historical order guidance page exists, then generate the page view data for the new order guidance page based on the key fields of the file and the historical order guidance page; If no historical order guidance page exists, then generate the page view data for the order guidance page based on the key fields of the file and the guidance page template.

10. The generation method according to claim 9, wherein, The page view data for generating a new order guidance page based on the key fields of the file and the historical order guidance pages includes: Identify the first differences between the key fields of the document and the page content of the historical order guidance page; Update the page view data of the historical order guidance page according to the first difference content, and configure the first difference content to be highlighted in the modified page view data.

11. The generation method according to claim 9, wherein, The process of generating page view data based on the key fields of the file also includes: By comparing the key fields of the document with the multiple required fields and / or preset fields on the order guidance page, if the key fields of the document are missing at least one required field and / or inconsistent with the preset fields, a highlighting rendering effect is configured for the missing required field and / or inconsistent field in the page view data of the order guidance page.

12. The generation method according to claim 1, wherein, Also includes: Obtain the modification operation submitted by the client based on the order guidance page, and update the page view data based on the modification operation; Identify the second difference between the updated page view data and the transaction intent document, and configure a highlighting rendering effect for the second difference in the updated page view data.

13. The generation method according to any one of claims 10-12, wherein, In addition to configuring the highlighted rendering effect, corresponding explanatory prompts are added to the page view data.

14. The generation method according to claim 1, wherein, Also includes: Obtain the order confirmation submitted on the order guidance page and generate the corresponding electronic transaction order.

15. A method for processing electronic transaction orders, comprising: Receive session messages containing files sent by the seller during the transaction session; The page view data of the order guidance page is received. The page view data is generated based on the parsing result of the target file carried in the session message. The page view data is generated when the target file is identified as a transaction intention file according to the parsing result of the target file. The target file is parsed by calling a multimodal recognition model. The order guidance page is loaded based on the page view data, and the electronic transaction order is confirmed based on the content of the order guidance page.

16. The processing method according to claim 15, wherein, Also includes: Receive modification operations submitted based on the order guidance page, obtain page view data updated based on the modification operations, and reload the order guidance page based on the updated page view data; Specifically, a highlighting rendering effect is configured for the second difference between the updated page view data and the transaction intent document.

17. The processing method according to claim 15, wherein, Also includes: The system receives the order confirmation request submitted on the order guidance page, retrieves the corresponding electronic transaction order, and loads the page corresponding to the electronic transaction order.

18. An electronic device comprising a memory, a processor, and a computer program stored in the memory, wherein the processor, when executing the computer program, implements the method of any one of claims 1-17.

19. A computer-readable storage medium storing a computer program that, when executed by a processor, implements the method of any one of claims 1-17.

20. A computer program product, wherein, The computer program product includes a computer program that, when executed by a processor, implements the method described in any one of claims 1-17.

Images