A control method for integrating multi-platform data distribution and collection

Abstract

The application discloses a kind of integrated multi-platform data distribution and control method of collection, comprising: constructing order field mapping rule library, the order data of each catering take-out platform is converted into the order data of uniform standard format;Using order decoding module, the order data of standard format is decoded and format conversion, print order and the execution state and time progress of each meal preparation task are monitored in real time;Large batch order is identified, and large batch order is handled by single order;The delivery status of order is updated in real time, and the latest delivery information is pushed to customer;Based on order delivery data and weather data, predict the overtime risk and overtime phase of order;Judge whether merchant agrees to return or order, and merchant confirmation information is synchronized to catering take-out platform.The application improves the intelligent level of order processing, delivery task allocation and delivery monitoring, significantly improves the operation efficiency and service quality of take-out platform, and optimizes the dining experience of customer.

Description

Technical Field

[0001] This invention relates to the field of next-generation information technology, and in particular to a control method for integrating multi-platform data distribution and aggregation. Background Technology

[0002] With the rapid development of the food delivery industry, the number and scale of food delivery platforms are constantly growing, and more and more catering businesses rely on these platforms to receive and process orders. However, despite significant progress in some aspects, the food delivery industry still faces a series of pressing problems, especially in data management, order processing, and delivery efficiency. Particularly with the increase in order volume and the diversification of consumer demands, traditional food delivery systems and management methods are struggling to meet the high-efficiency operational needs of the modern food delivery industry. First, the data format differences between food delivery platforms severely impact the work efficiency of both merchants and delivery personnel. Currently, the catering food delivery industry has multiple different platforms, each using different data formats. Merchants must interface with and process order data according to the requirements of each platform. This data incompatibility between different platforms requires additional manual intervention and adjustments when processing orders from multiple platforms, increasing operating costs and easily leading to data processing errors or omissions. This lack of data format uniformity results in data redundancy, error transmission, and duplicate entry of order information, placing an additional burden on merchants. Second, monitoring food delivery orders during the processing process remains a significant challenge. Especially during peak periods and with large order volumes, merchants and delivery personnel often face the challenge of efficiently scheduling and allocating tasks. Currently, most food delivery platforms rely on manual judgment or simple rules to assign tasks, lacking an effective real-time monitoring system to track the progress of food preparation. Because merchants cannot promptly understand the real-time status of order processing, problems such as orders not being prepared on time and delivery personnel having too many tasks concentrated on one side can easily occur, leading to order delays and reduced delivery quality. This lack of efficient monitoring and scheduling mechanisms is particularly prominent in the food delivery industry, severely impacting the customer's dining experience. These problems significantly affect the operational efficiency of food delivery platforms, increase the burden on both merchants and customers, and negatively impact the customer's dining experience. Therefore, an efficient and intelligent solution is urgently needed to optimize the entire food delivery order processing and delivery workflow. Summary of the Invention

[0003] To address the problems existing in the prior art, this invention provides a control method for integrated multi-platform data distribution and aggregation, mainly comprising:

[0004] By acquiring order data from various food delivery platforms through an integrated ordering system, constructing an order field mapping rule library, and converting the order data from various food delivery platforms into order data in a unified standard format;

[0005] The order decoding module decodes and converts standard format order data, converts it into order data in the preset standard order data format of the integrated order system, sends it to the merchant's integrated order system, prints the order, and monitors the execution status and time progress of each food preparation task in real time.

[0006] Based on the parsed and standardized order data, identify large batches of orders, break them down into multiple smaller order delivery tasks, and assign them to delivery personnel.

[0007] The integrated ordering system updates the delivery status of orders in real time and pushes the latest delivery information to customers.

[0008] The integrated ordering system obtains order status in real time, identifies overdue orders and overdue stages, predicts overdue risks and overdue stages based on order delivery data and weather data, and sends overdue order warning information to merchants, delivery personnel and customers;

[0009] Based on the order cancellation data obtained from the food delivery platform, determine whether the merchant agrees to the return or cancellation, and synchronize the merchant's confirmation information to the food delivery platform.

[0010] Furthermore, the step of acquiring order data from various food delivery platforms through an integrated ordering system, constructing an order field mapping rule base, and converting the order data from various food delivery platforms into order data in a unified standard format includes:

[0011] Order data from various food delivery platforms is obtained through the API interface of the integrated ordering system. This data includes customer order information and order cancellation requests. Customer order information includes order ID, customer information, menu list, price, merchant information, platform information, customer remarks, and order time. Order cancellation requests include the reason for cancellation, customer ID, platform information, order ID, and cancellation time. Field definitions from the order data of major food delivery platforms are obtained through the API interface of the integrated ordering system. Fields in the obtained order data are manually labeled, assigning each field a unique standardized identifier and a unified standard name. An order field mapping rule library is constructed to record the correspondence between different order fields across different platforms, and this library is updated regularly. Based on the obtained order data from various food delivery platforms, a multi-layered data parsing algorithm is used, according to the order field mapping rule library, to convert the order data from each platform into a unified standard format, and missing data is supplemented.

[0012] Furthermore, the order decoding module decodes and converts the standard format order data, transforming it into order data in the integrated ordering system's preset standard order data format, and sends it to the merchant's integrated ordering system. This process includes printing the order and real-time monitoring of the execution status and progress of each food preparation task, including:

[0013] Based on the pre-set decoding rule set built into the integrated ordering system, the system obtains the original format definitions and decoding parameters of orders from various platforms. The decoding rule set includes different platform order formats, field names, field types, and platform-specific marking methods. Using the obtained decoding parameters, the order decoding module decodes the standard format order data and converts it into the integrated ordering system's pre-set standard order data format. Through a network interface, the converted order data is sent to the merchant's integrated ordering system, and the order is printed. The merchant's integrated ordering system receives and obtains the parsed and standardized order data. Based on the quantity, specifications, and customer remarks in the order, the task management module generates a food preparation task list. The system processes orders and executes food preparation tasks. Through the integrated ordering system's monitoring module, the execution status and progress of each food preparation task are monitored in real time, recording and displaying the progress. Based on real-time and historical monitoring data, the isolated forest algorithm is used to determine if there are delays in food preparation progress. If a step in the food preparation task fails to complete within the scheduled time, a long short-term memory network is used to train a model based on the real-time monitoring data to predict the completion time of the delayed task and trigger an abnormal progress alert. Delayed dishes are given priority processing, and the alert includes the delayed dish and its estimated completion time. If the food preparation task is completed, the order is marked as completed, and the order data is sent to the delivery system.

[0014] Furthermore, the process of identifying large-volume orders based on the parsed and standardized order data, splitting these large-volume orders into multiple smaller delivery tasks, and assigning them to delivery personnel includes:

[0015] The system obtains the number of dishes from the parsed and standardized order data obtained through the merchant's integrated ordering system. If the number of dishes exceeds a preset threshold, the order is considered a bulk order. Based on the order information of the bulk order, the system obtains the number of dishes, dish types, and the merchant's dish inventory data. Dish types include soups, stir-fries, and staple foods. If the merchant's dish inventory data meets the order's dish quantity, the system determines the delivery requirements for different dishes based on their types. Combining this with the workload data of nearby delivery personnel, the system determines the dish combination for each smaller order, splitting the bulk order into smaller orders. Delivery requirements include delivery time and packaging requirements. If a dish in a bulk order has special delivery needs, the system performs targeted order splitting adjustments for that dish, prioritizing it or assigning it to a separate smaller order. Multiple smaller order delivery tasks are generated based on the split smaller orders, assigned to delivery personnel, and the merchant's dish inventory data is updated synchronously based on the smaller order order data.

[0016] This also includes determining the delivery requirements for different dishes based on their type, and combining this with data on the work status of nearby delivery personnel to determine the dish combination for each small order, thus breaking down large orders into smaller ones. Specifically, this includes:

[0017] By using the delivery driver management module of the integrated ordering system, the workload data of delivery drivers within a preset distance from the merchant is obtained to determine the delivery driver load. Among them, L i T is the total load of deliveryman i. ij Let be the time required for delivery person i to execute order j, and n be the number of orders currently handled by delivery person i; according to the delivery task allocation formula for delivery personnel. Determine whether a delivery driver can handle smaller orders after a large batch of orders is broken down into smaller ones, where X... ij C represents the number of small orders j assigned to delivery person i. j For the quantity of dishes in a large order j, W j S is a packaging coefficient, representing the packaging complexity of each dish. It is obtained by setting preset values ​​for different packaging requirements. i K represents the number of dishes that delivery person i can handle. j The maximum load capacity for each small order j; the delivery task load optimization formula is used based on the deliveryman's speed and the distance of each task. Determine the shortest time P required for the delivery person to complete the order. i , among which, T i V represents the total time required for delivery person i. i Let A be the number of deliveries that delivery person i can complete per unit of time. j B represents the distance the delivery person takes from their current location to the destination. iThe number of tasks that delivery person i can handle simultaneously; based on the delivery time and packaging requirements of the dishes in the bulk orders, combined with whether the delivery person can handle small orders and the shortest time required for the delivery person to complete the orders, the dish combination of each small order is determined, and the bulk orders are split into small orders.

[0018] Furthermore, the method of updating the delivery status of orders in real time through the integrated ordering system and pushing the latest delivery information to customers includes:

[0019] The integrated ordering system obtains the delivery person's current location and feedback information in real time, updates the order's delivery status synchronously, and pushes the latest delivery information to customers. If a delivery abnormality occurs during the delivery process, the integrated ordering system sends a notification message to the merchant and customer until the delivery person reports that the order has been delivered. The order status is then updated to "completed". Delivery abnormalities include the delivery person failing to pick up the goods on time and the delivery route being inappropriate.

[0020] Furthermore, the integrated ordering system obtains order status in real time, identifies overdue orders and overdue stages, predicts order overdue risks and overdue stages based on order delivery data and weather data, and sends order overdue warning information to merchants, delivery personnel, and customers, including:

[0021] The integrated ordering system's real-time monitoring module acquires order status in real time and records it in the order monitoring database. Order status includes order creation, food preparation start, food preparation complete, delivery start, delivery in progress, and delivery complete. A push notification module sends notifications of each order status change to relevant merchants and customers. Based on the real-time updated order status, the integrated ordering system's anomaly detection module monitors orders. If an order times out at any stage, it is automatically marked as an overdue order, and the overdue stage is indicated. Historical order delivery data, including order status change records, delivery time, food preparation time, and delivery route, is obtained through the merchant's integrated ordering system and monitored in real time. The system provides real-time status updates for current orders; it also acquires historical workload data for each delivery person through the delivery person management module of the integrated ordering system, including the number of delivery tasks, the number of orders currently being handled, and delivery time; based on historical order delivery data, delivery person historical workload data, and historical weather data, and by labeling historical overdue orders and overdue stages, it uses a support vector machine algorithm to train a model and construct an order overdue prediction model to predict the overdue risk and overdue stage of the current order. Weather data includes temperature, wind speed, and rainfall; and based on the prediction results of orders with overdue risk, it sends order overdue warning information to merchants, delivery persons, and customers through the push notification module of the integrated ordering system.

[0022] Furthermore, the step of determining whether a merchant agrees to a return or cancellation based on customer order cancellation data obtained from the food delivery platform, and synchronizing the merchant's confirmation information to the food delivery platform, includes:

[0023] Based on customer order cancellation requests obtained from the food delivery platform, the data is converted using a pre-set standard data format of the integrated ordering system to obtain the converted standard data format for cancellation requests. This data includes the reason for cancellation, order ID, customer information, menu item list, quantity, and cancellation time. Based on the cancellation data received from the integrated ordering system, the system determines whether the merchant agrees to the return or cancellation. If the merchant agrees, a confirmation cancellation message is generated; if not, a rejection is recorded and a notification is sent. Finally, based on the merchant's confirmed return or cancellation information, the system synchronizes the merchant's confirmation information to the food delivery platform via the integrated ordering system's API interface.

[0024] The technical solutions provided by the embodiments of the present invention may include the following beneficial effects:

[0025] This invention provides a control method for integrated multi-platform data distribution and aggregation. By constructing an order field mapping rule base, this invention can automatically convert order data from different platforms into a standard format. An order decoding module then decodes this standard format order data, converting it into the preset standard order data format of the integrated ordering system. This reduces manual intervention and errors caused by inconsistent data formats, lowering operating costs. Simultaneously, real-time monitoring allows merchants to efficiently track the progress of food preparation tasks, ensuring timely processing of large batches of orders, avoiding order omissions and delays, and improving food preparation efficiency and order processing accuracy. This invention solves the problems of uneven workload and unreasonable task allocation in large-volume order delivery through intelligent order splitting and task allocation mechanisms. Based on the type of dish and the delivery person's work status, it automatically splits large batches of orders and optimizes the delivery person's workload and delivery route, effectively improving delivery efficiency and ensuring that delivery personnel are not overworked due to excessive workloads, reducing delivery delays. This invention, through real-time order status updates and intelligent timeout prediction, can provide early warnings of potential delays and promptly push delivery status information to merchants, delivery personnel, and customers. This not only improves the accuracy of customers' order expectations but also reduces customer complaints caused by delivery delays, significantly enhancing customer satisfaction. Furthermore, by improving the intelligence level of order processing, delivery task allocation, and delivery monitoring, this invention significantly improves the operational efficiency and service quality of food delivery platforms, optimizing the customer's dining experience. Attached Figure Description

[0026] Figure 1 This is a flowchart of a control method for integrating multi-platform data distribution and aggregation according to the present invention;

[0027] Figure 2 This is a schematic diagram of a control method for integrating multi-platform data distribution and aggregation according to the present invention;

[0028] Figure 3 This is another schematic diagram of a control method for integrating multi-platform data distribution and aggregation according to the present invention. Detailed Implementation

[0029] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be described in detail below with reference to the accompanying drawings and specific embodiments.

[0030] like Figure 1-3 This embodiment of a control method for integrating multi-platform data distribution and aggregation may specifically include:

[0031] Step S101: Obtain order data sent by various food delivery platforms through the integrated ordering system, construct an order field mapping rule library, and convert the order data of various food delivery platforms into order data in a unified standard format.

[0032] Order data from various food delivery platforms is obtained through the API interface of the integrated ordering system. This data includes customer order information and order cancellation requests. Customer order information includes order ID, customer information, menu list, price, merchant information, platform information, customer remarks, and order time. Order cancellation requests include the reason for cancellation, customer ID, platform information, order ID, and cancellation time. Field definitions from the order data of major food delivery platforms are also obtained through the API interface of the integrated ordering system. Fields in the obtained order data are manually labeled, assigning each field a unique standardized identifier and a unified standard name. An order field mapping rule library is constructed to record the correspondence between different order fields across different platforms, and this library is updated regularly. Based on the obtained order data from various food delivery platforms, a multi-layered data parsing algorithm is used, according to the order field mapping rule library, to convert the order data from each platform into a unified standard format, and missing data is supplemented.

[0033] For example, food delivery platforms A, B, and C send order data to an integrated ordering system. Platform A's order data includes the customer's order ID, customer information, menu list, price, merchant information, platform information, customer remarks, and order time. Platforms B and C have different order data formats and fields, so the system needs to perform format conversion and standardization after receiving this data. The integrated ordering system obtains Platform A's order data through an API interface. Platform A's order data includes an order ID of 10001, customer information including customer ID C001 and contact information 13800000001, a menu including one serving of Mala Xiangguo (Spicy Stir-fry) and two servings of Kung Pao Chicken, a total price of 78 yuan, merchant information as Merchant A, platform information as Platform A, customer remarks as "no spice," and order time as 2020-01-01-18:30:00. Similarly, Platform B and Platform C also send data in similar formats, but their field naming and structures may differ. For example, Platform B might use OrderID instead of Order ID, CustomerName instead of customer information, and the menu might be presented in different formats. To unify this data, the system receives the data and preprocesses it using a format conversion module. Based on the field definitions of Platform A, the system maps the order data from Platform B and Platform C to a unified standard format, such as mapping OrderID to Order ID and CustomerName to customer information. During this process, the system records the standard names of the corresponding fields in Platform B and Platform C according to the order field mapping rule base. In this way, order data from platforms A, B, and C are all converted into a unified standard format, such as order ID 10001, customer ID C001, dishes 1 serving of Mala Xiangguo (Spicy Hot Pot) and 2 servings of Kung Pao Chicken, price 78 yuan, merchant A, platform A, customer remarks "no spice," and order time 2020-01-01-18:30:00. These order data undergo manual annotation, assigning each field a unique standardized identifier and unified name. For example, order ID might correspond to identifier field_001, customer information to field_002, etc. All field mapping rules are recorded in the order field mapping rule library and updated regularly to ensure that new platform field definitions are promptly incorporated into the standard library. During the conversion process, if certain fields are missing in the data of platform B or C, the system uses preset filling rules to supplement them. If the order data of platform B is missing the customer remarks field, the system will fill it in as "no remarks" to maintain data integrity, and these supplemented and converted order data are sent to the integrated ordering system.

[0034] Step S102: The order data in the standard format is decoded and converted using the order decoding module. The converted order data is then sent to the merchant's integrated ordering system in the preset standard order data format. The order is printed and the execution status and time progress of each food preparation task are monitored in real time.

[0035] Based on the built-in preset decoding rule set of the integrated ordering system, the original format definitions and decoding parameters of orders from various platforms are obtained. The decoding rule set includes order formats, field names, field types, and platform-specific marking methods for different platforms. According to the obtained decoding parameters, the order decoding module decodes the standard format order data and converts it into the preset standard order data format of the integrated ordering system. The converted order data is sent to the merchant's integrated ordering system via a network interface, and the order is printed. The merchant's integrated ordering system receives and obtains the parsed and standardized order data. Based on the quantity, specifications, and customer remarks in the order, the task management module generates a food preparation task list and executes the food preparation tasks. The monitoring module of the integrated ordering system monitors the execution status and progress of each food preparation task in real time, recording and displaying the progress. Based on the real-time and historical monitoring data of the food preparation tasks, the isolated forest algorithm is used to determine whether there are delays in the food preparation progress. If a step in the food preparation task fails to be completed within the scheduled time, a long short-term memory network is used to train a model based on real-time monitoring data of the food preparation task. This model predicts the completion time of the delayed food preparation task and triggers an alert for abnormal food preparation progress. Delayed dishes are given priority processing, and the alert information includes the delayed dish and its estimated completion time. If the food preparation task is completed, the order is marked as completed, and the order data is sent to the delivery system.

[0036] For example, food delivery platform B receives a customer's order and transmits the order data to an integrated ordering system via an API interface. The order data includes the customer's basic information, a menu list, prices, and merchant information. Platform B's order format and field definitions differ from other platforms. Therefore, the integrated ordering system obtains the original order format definition and decoding parameters from Platform B based on Platform B's decoding rule set. Platform B's decoding rule set includes field names such as `order_id`, `customer_info`, and `menu_items`, field types, and unique marking methods. Field types include `string` and `integer`, and unique marking methods, such as Platform B using `#` as a field separator. After obtaining these decoding parameters, the integrated ordering system decodes the original standard format order data using the order decoding module. The decoded order data sent by Platform B includes: `order_id:10001#customer_info:C001#menu_items:1 serving of Mala Xiangguo,2 servings of Kung Pao Chicken#price:78 yuan#remark:no spice`. During decoding, these fields are converted into the standard order data format preset by the integrated ordering system, such as order ID 10001, customer ID C001, dishes 1 serving of Mala Xiangguo (Spicy Hot Pot), 2 servings of Kung Pao Chicken, total price 78 yuan, and remarks "no spice". The decoded order data is sent to the merchant's integrated ordering system via a network interface and printed on the merchant's system. After receiving the order, the merchant's system generates a food preparation task list based on the quantity, specifications, and customer remarks in the order. The merchant's integrated ordering system starts executing the food preparation tasks through the task management module, and monitors the execution status and progress of each task in real time, displaying this information to the kitchen staff. As the execution time of a task approaches the scheduled time, the monitoring module continuously checks the completion status of each step. During the food preparation process, the integrated ordering system uses the Isolation Forest algorithm to analyze the execution status of each task to determine if there are any delays in food preparation. If a step is not completed within the scheduled time, such as the cooking step of Kung Pao Chicken exceeding the time limit, the system will use a Long Short-Term Memory (LSTM) network for training. Based on historical data and real-time monitoring data, it will predict the estimated completion time of the task. If the system predicts that the Kung Pao Chicken will be completed within 15 minutes, exceeding the preset time threshold of 12 minutes, an exception alert will be triggered to notify the kitchen, instructing that the dish needs to be prioritized. Once the food preparation task is completed, the integrated ordering system will mark the order as complete and send the order data to the delivery system to begin the delivery process.

[0037] Step S103: Based on the parsed and standardized order data, identify large-volume orders, split the large-volume orders into multiple small-order delivery tasks, and assign them to delivery personnel.

[0038] The order data obtained from the merchant's integrated ordering system, after parsing and standardizing, is used to determine the quantity of dishes. If the quantity exceeds a preset threshold, the order is considered a bulk order. Based on the bulk order information, the quantity and type of dishes, along with the merchant's inventory data, are retrieved. Dish types include soups, stir-fries, and staple foods. If the merchant's inventory meets the order's quantity requirements, delivery requirements are determined based on dish type. Combined with nearby delivery rider workload data, the dish combination for each smaller order is determined, splitting the bulk order into smaller orders. Delivery requirements include delivery time and packaging. If a bulk order contains dishes with special delivery needs, the order is split accordingly, prioritizing or assigning the dish to a separate smaller order. Multiple smaller order delivery tasks are generated based on the split smaller orders, assigned to delivery riders, and the merchant's inventory data is updated synchronously based on the smaller order data.

[0039] For example, through a merchant's integrated ordering system, parsed and standardized order data is obtained, including information such as the quantity and type of dishes, and special delivery requirements. If an order contains 150 servings of Mala Xiangguo (Spicy Hot Pot), 120 servings of Mushroom Soup, and 80 servings of Rice, totaling 350 dishes, exceeding the preset threshold of 50 servings, it is determined to be a large-volume order. By accessing merchant B's inventory data through the integrated ordering system, it is found that there are 200 servings of Mala Xiangguo, 150 servings of Mushroom Soup, and 100 servings of Rice. Based on the dish type, Mala Xiangguo belongs to the stir-fry category, Mushroom Soup belongs to the soup category, and Rice belongs to the staple food category. Merchant B determines based on the inventory data that the quantity of dishes in this order does not exceed the inventory, therefore Merchant B can fulfill the order demand. Based on the dish type and combined with the workload data of nearby delivery personnel, the large-volume order is broken down into multiple smaller orders. During the order splitting process, the delivery requirements for each small order are considered, including delivery time and packaging requirements. For example, Mala Xiangguo (a type of spicy stir-fry) might require special regular packaging, while mushroom soup requires temperature-controlled packaging, and rice requires regular packaging. This information is used to determine the food combination for each small order. For instance, 80 servings of Mala Xiangguo, 40 servings of mushroom soup, and 50 servings of rice might be combined into one small order, while the remaining 40 servings of Mala Xiangguo are split into a separate small order. The remaining rice and mushroom soup are split according to quantity, ensuring that the delivery requirements of each small order are met. If a large batch of orders contains dishes with special delivery requirements, such as grilled fish hot pot, which requires temperature-controlled packaging, the system will prioritize these orders and may even assign them to separate small orders to ensure that the temperature control equipment functions properly during delivery and to maintain the quality and temperature of the food as much as possible. These special small orders are marked as priority delivery tasks and assigned to delivery personnel with suitable delivery capabilities. Finally, multiple small order delivery tasks are generated based on the split small orders and assigned to nearby delivery personnel. Each delivery person's tasks will be rationally allocated based on their current work status and workload to ensure that no delivery person's workload is overloaded. At the same time, the system will synchronously update Merchant B's food inventory data, reducing the inventory of Mala Xiangguo to 50 servings, mushroom soup to 30 servings, and rice to 20 servings.

[0040] Based on the type of dish, determine the delivery requirements for different dishes, and combine the work status data of nearby delivery personnel to determine the dish combination for each small order, thus breaking down large orders into smaller orders.

[0041] By using the delivery driver management module of the integrated ordering system, the workload data of delivery drivers within a preset distance from the merchant is obtained to determine the delivery driver load. Among them, L i T is the total load of deliveryman i. ijLet be the time required for delivery person i to execute order j, and n be the number of orders currently handled by delivery person i. This is based on the delivery task allocation formula for delivery personnel. Determine whether a delivery driver can handle smaller orders after a large batch of orders is broken down into smaller ones, where X... ij C represents the number of small orders j assigned to delivery person i. j For the quantity of dishes in a large order j, W j S is a packaging coefficient, representing the packaging complexity of each dish. It is obtained by setting preset values ​​for different packaging requirements. i K represents the number of dishes that delivery person i can handle. j The maximum load capacity for each small order j. The delivery task load optimization formula is used based on the deliveryman's speed and the distance of each task. Determine the shortest time P required for the delivery person to complete the order. i , among which, T i V represents the total time required for delivery person i. i Let A be the number of deliveries that delivery person i can complete per unit of time. j B represents the distance the delivery person takes from their current location to the destination. i The number of tasks that delivery person i can handle simultaneously. Based on the delivery time and packaging requirements of the dishes in the bulk orders, combined with whether the delivery person can handle small orders and the shortest time required for the delivery person to complete the orders, the dish combination of each small order is determined, and the bulk orders are broken down into small orders.

[0042] For example, Merchant C receives a large group meal order from a major client during the lunch rush, comprising 50 dishes. These include 20 servings of roasted chicken wings (packaging coefficient W = 1.2), 20 servings of lamb skewers (packaging coefficient W = 1.0), and 10 servings of vegetable salad (packaging coefficient W = 0.8). The workload of three delivery drivers within a 1-kilometer radius of Merchant C is obtained through an integrated ordering system. Taking delivery driver A as an example, he is currently handling two orders, each with an estimated delivery time of 15 minutes and 12 minutes respectively. Therefore, delivery driver A's total workload is 27 minutes, according to the formula... Determine the total load L of deliveryman i i It lasted 27 minutes, of which T ij Let be the time required for delivery person i to execute order j, and n be the number of orders currently handled by delivery person i. Based on delivery person A's maximum food carrying capacity of 40, the total number of food items in the order of 50, and considering packaging complexity, the delivery task allocation formula for delivery persons is used. Get X ij =1.3, indicating that under the current conditions, delivery person A can only undertake a delivery task equivalent to a maximum of 1.3 units. The determination is made based on whether delivery person A can accept smaller orders after large orders are broken down into smaller orders. Where X... ijC represents the number of small orders j assigned to delivery person i. j For the quantity of dishes in a large order j, W j S is a packaging coefficient, representing the packaging complexity of each dish. It is obtained by setting preset values ​​for different packaging requirements. i K represents the number of dishes that delivery person i can handle. j The maximum load capacity for each small order j. Delivery person A's distance from their current location to the merchant is 1.2 km, their average delivery speed is 0.1 km / min, and they have 2 delivery tasks. The expected maximum delivery time for this small order is 30 minutes. Based on the delivery person's delivery task load optimization formula... Determine the shortest time P required for the delivery person to complete the order. i It lasts for 12 minutes, of which T i V represents the total time required for delivery person i. i Let A be the number of deliveries that delivery person i can complete per unit of time. j B represents the distance the delivery person takes from their current location to the destination. i This represents the number of tasks that delivery person i can handle simultaneously. This means that delivery person A, starting from their current location, has a theoretically minimum completion time of 12 minutes, which is within the 30-minute requirement. Therefore, the system determines that this delivery person meets the conditions in terms of both load and time, and can handle a certain amount of food. Ultimately, they are assigned 6 portions of grilled chicken wings, 5 portions of lamb skewers, and 2 portions of salad, ensuring that delivery person A's delivery tasks neither exceed the load limit nor fall within the time tolerance range.

[0043] Step S104: Update the delivery status of the order in real time through the integrated ordering system and push the latest delivery information to the customer.

[0044] The integrated ordering system obtains the delivery driver's current location and feedback information in real time, updates the order's delivery status synchronously, and pushes the latest delivery information to customers. If a delivery abnormality occurs during the delivery process, the integrated ordering system sends a notification message to the merchant and customer until the delivery driver reports that the order has been delivered, at which point the order status is updated to "completed." Delivery abnormalities include the delivery driver failing to pick up the goods on time and inappropriate delivery routes.

[0045] For example, on January 2, 2020, at 11:50 AM, Customer 1 placed an order through food delivery platform A for a Sichuan restaurant in the city center, including a dish of shredded pork with garlic sauce and a dish of hot and sour shredded potatoes. The integrated ordering system automatically assigned the order to deliveryman B, who was approximately 0.8 kilometers from the restaurant. The system tracked deliveryman B's location in real time and displayed on a map that he was about a 4-minute bike ride from the restaurant. Simultaneously, the system sent a pickup notification to the restaurant, reminding deliveryman B to arrive before 11:55 AM. Customer 1's phone screen also displayed: "Deliveryman B has accepted the order, estimated delivery time 12:15 PM." At 11:54 AM, the system detected that deliveryman B was still stationary and immediately sent a notification to him: "You haven't set off yet, are you having any problems?" Deliveryman B replied: "I was delayed by the previous order, I expect to pick up the food at 12:05 PM." The system automatically identified this as a delivery anomaly due to a missed pickup and immediately sent notifications to both the merchant and customer 1: "Due to a delay in the previous order, the estimated pickup time is 10 minutes later. Please wait patiently." The merchant accordingly delayed packaging to prevent the food from getting cold. At 12:06, the system detected that delivery person B had departed from their current location and updated their location in real time; the delivery track on customer 1's phone also began to move. However, the system detected that delivery person B had chosen a main road prone to congestion during peak hours, extending the estimated arrival time to 12:30, exceeding the platform's maximum delay tolerance of 15 minutes. The system sent another anomaly notification: "The current route may cause a delay; it is recommended to replan the route." Upon seeing this, delivery person B changed to a faster side road. At 12:18, delivery person B arrived at customer 1's neighborhood and clicked "delivered." Upon receiving this feedback, the system automatically updated the order status to "completed" and sent a message thanking customer 1 for using the service.

[0046] Step S105: Obtain order status in real time through the integrated ordering system, identify overdue orders and overdue stages, predict the overdue risk and overdue stage of orders based on order delivery data and weather data, and send order overdue warning information to merchants, delivery personnel and customers.

[0047] The integrated ordering system's real-time monitoring module acquires order status in real time and records it in the order monitoring database. Order status includes order creation, food preparation start, food preparation complete, delivery start, delivery in progress, and delivery complete. A push notification module sends notifications of each order status change to relevant merchants and customers. Based on the real-time updated order status, the integrated ordering system's anomaly detection module monitors orders. If an order times out at any stage, it is automatically marked as an overdue order, and the overdue stage is indicated. Through the merchant's integrated ordering system, historical order delivery data is obtained, including order status change records, delivery time, food preparation time, and delivery route. The real-time monitoring module also acquires current order status change data. Finally, the integrated ordering system's delivery driver management module obtains historical workload data for each delivery driver, including the number of delivery tasks, the current order load, and delivery time. Based on historical order delivery data, delivery personnel's historical workload data, and historical weather data, and by labeling historical overdue orders and their durations, a support vector machine (SVM) algorithm is used to train a model to construct an order overdue prediction model. This model predicts the risk of overdue orders and their duration. Weather data includes temperature, wind speed, and rainfall. Based on the predicted overdue risk orders, order overdue warnings are sent to merchants, delivery personnel, and customers via the push notification module of the integrated order system.

[0048] For example, on food delivery platform C, customer 2 ordered a fried chicken meal from a Western fast food restaurant at 12:00 on January 2, 2020. The order was recorded and its status was updated to "Order Created." The integrated ordering system's real-time monitoring module began tracking the order's status. The merchant started preparing the food at 12:05, and the system automatically updated the order status to "Preparation Begins." During food preparation, the real-time monitoring module synchronized information with the merchant's integrated ordering system and recorded the start time of preparation. At 12:25, the merchant completed food preparation and updated the system status to "Preparation Completed." The system promptly pushed this status change to customer 2 and displayed the estimated delivery time as 12:45. At this point, delivery driver C received the order and began delivery at 12:30, and the system updated the order status to "Delivery Begins." However, due to heavy traffic, delivery driver C chose a congested route. The system, through the real-time monitoring module, monitored the delivery driver's current location and estimated arrival time. At 12:50, the system detected that delivery person C had exceeded the preset delivery time by 15 minutes and failed to deliver on time, thus determining that the order had entered a timeout state. The integrated ordering system automatically marked the order as timed out and indicated the timeout period as "in progress." The system then sent a warning message about the timeout to the merchant, delivery person, and customer 2, indicating an estimated delivery time of 13:00. To more accurately predict the risk of similar orders exceeding the time limit, the platform uses historical order data and delivery personnel's historical workload data for machine learning training. Through the merchant's integrated ordering system, it obtains historical order data from the past 30 days, including order status changes, delivery time, food preparation time, and delivery route. Through the delivery personnel management module of the integrated ordering system, it obtains historical workload data for each delivery person from the past 30 days, including the number of delivery tasks, the number of orders currently being handled, and delivery time. Combined with historical weather data from the past 30 days, the platform uses a support vector machine algorithm to build an order timeout prediction model. Based on this model, the system can calculate the timeout risk of the current order in real time and automatically issue a warning when the timeout risk reaches a certain threshold. Weather data includes temperature, wind speed, and rainfall. If the integrated ordering system receives another order and predicts a 20% probability that the delivery person will exceed the time limit within 15 minutes, it will notify the merchant and customer in advance via push notification. Ultimately, through the system's precise monitoring and early warning mechanisms, merchants can adjust their order delivery strategies in a timely manner, delivery personnel can choose more suitable routes, and customers can have a clearer understanding of their order status, thus improving the user experience.

[0049] Step S106: Based on the order cancellation request data obtained by the food delivery platform, determine whether the merchant agrees to the return or cancellation, and synchronize the merchant confirmation information to the food delivery platform.

[0050] Based on customer order cancellation requests obtained from the food delivery platform, the data is converted using a pre-set standard data format of the integrated ordering system to obtain the converted standard data format for cancellation requests. This data includes the reason for cancellation, order ID, customer information, menu item list, quantity, and cancellation time. Based on the cancellation data received from the integrated ordering system, the system determines whether the merchant agrees to the return or cancellation. If the merchant agrees, a confirmation cancellation message is generated; if not, a rejection is recorded and a notification is sent. Based on the merchant's confirmed return or cancellation information, the system synchronizes the merchant's confirmation information to the food delivery platform via the integrated ordering system's API interface.

[0051] For example, on food delivery platform A, customer 3 ordered a spicy hot pot set meal at 12:30 on January 2, 2020. The order ID was 11012. The set meal included one serving of spicy beef, two servings of tripe, one serving of potato slices, and one serving of rice, with a total order amount of 98 yuan. After the order was placed, the merchant completed the food preparation and started delivery at 12:40, following the normal process. However, during the delivery process, customer 3 decided to cancel the order and apply for a refund for personal reasons. At 13:20, customer 3 submitted a refund application through the platform, selecting delivery delay as the reason for the refund, and provided detailed information, including refund application ID 7891011, customer ID C22, and customer contact number 13912341234. The data for the order cancellation request was converted according to the preset standard data format of the integrated ordering system. The data included customer ID, order ID, menu item list, quantity of each item, reason for cancellation, and cancellation time. After conversion, the data format was standardized as follows: Order ID 11012, Customer ID C22, Customer contact number 13912341234, Menu item list: Spicy Beef, Tripe, Potato Slices, Rice, Quantity: 1 serving of Spicy Beef, 2 servings of Tripe, 1 serving of Potato Slices, 1 serving of Rice, Reason for cancellation: Delivery Delay, Time of cancellation: 2020-01-02-13:20. The converted data was immediately transmitted to the merchant's backend through the integrated ordering system for processing. After receiving the cancellation data, the merchant internally verified that the delivery delay exceeded the platform's preset time limit due to traffic congestion encountered by the delivery person that day. The merchant approved the cancellation and confirmed the cancellation information through the merchant's system at 13:30, generating a confirmation cancellation notification. The merchant's confirmed cancellation information includes cancellation ID 012, cancellation request ID 7891011, reason for cancellation (delivery delay), cancellation time, and the merchant's approval mark. The merchant's confirmed cancellation information is synchronized to the food delivery platform via the integrated ordering system's API interface. Upon receiving the merchant's confirmation, the platform automatically processes Customer 3's cancellation request, updates the order status to "cancelled," and notifies Customer 3 of the refund processing information. At this time, Customer 3 also receives a push notification from the platform informing them that their refund request has been approved by the merchant and is being processed, expected to be completed within two business days. This process ensures automation and standardization throughout the entire process, from the customer submitting the cancellation request to the merchant agreeing to the cancellation, and then to the platform synchronizing the status and completing the refund. It also ensures timely synchronization and feedback of information from all parties through the integrated system, improving service efficiency and transparency.

[0052] The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the concept of this application. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this application.

Claims

1. A control method for integrating multi-platform data distribution and aggregation, characterized in that, The method includes: By acquiring order data from various food delivery platforms through an integrated ordering system, constructing an order field mapping rule library, and converting the order data from various food delivery platforms into order data in a unified standard format; The order decoding module decodes and converts standard format order data, converts it into order data in the preset standard order data format of the integrated order system, sends it to the merchant's integrated order system, prints the order, and monitors the execution status and time progress of each food preparation task in real time. Based on the parsed and standardized order data, identify large batches of orders, break them down into multiple smaller order delivery tasks, and assign them to delivery personnel. The integrated ordering system updates the delivery status of orders in real time and pushes the latest delivery information to customers. The integrated ordering system obtains order status in real time, identifies overdue orders and overdue stages, predicts overdue risks and overdue stages based on order delivery data and weather data, and sends overdue order warning information to merchants, delivery personnel and customers; Based on the order cancellation data obtained by the food delivery platform, determine whether the merchant agrees to the return or cancellation, and synchronize the merchant's confirmation information to the food delivery platform; The process of identifying large-volume orders based on parsed and standardized order data, splitting these large-volume orders into multiple smaller delivery tasks, and assigning them to delivery personnel includes: The system obtains the number of dishes from the parsed and standardized order data obtained through the merchant's integrated ordering system. If the number of dishes exceeds a preset threshold, the order is considered a bulk order. Based on the order information of the bulk order, the system obtains the number of dishes, dish types, and the merchant's dish inventory data. Dish types include soups, stir-fries, and staple foods. If the merchant's dish inventory data meets the order's dish quantity, the system determines the delivery requirements for different dishes based on their types. Combining this with the workload data of nearby delivery personnel, the system determines the dish combination for each smaller order, splitting the bulk order into smaller orders. Delivery requirements include delivery time and packaging requirements. If a dish in a bulk order has special delivery needs, the system performs targeted order splitting adjustments for that dish, prioritizing it or assigning it to a separate smaller order. Multiple smaller order delivery tasks are generated based on the split smaller orders, assigned to delivery personnel, and the merchant's dish inventory data is updated synchronously based on the order data of the smaller orders. The process of determining delivery requirements for different dishes based on their type, and combining this with data on the work status of nearby delivery personnel to determine the dish combination for each small order, thus breaking down large orders into smaller ones, includes: The delivery driver management module of the integrated ordering system obtains workload data of delivery drivers within a preset distance from the merchant to determine the delivery driver load. ,in, It is the total load of deliveryman i. Let n be the time required for delivery person i to execute order j, and n be the number of orders currently handled by delivery person i; according to the delivery task allocation formula for delivery personnel. To determine whether a delivery driver can handle smaller orders after a large batch of orders has been broken down, the following factors need to be considered: This represents the number of small orders j assigned to delivery person i. For the quantity of dishes in a large-volume order j, The packaging coefficient represents the packaging complexity of each dish, obtained through preset values ​​based on different packaging requirements. This indicates the number of dishes that delivery person i can handle. The maximum load capacity for each small order j; the delivery task load optimization formula is used based on the deliveryman's speed and the distance of each task. Determine the shortest time required for the delivery person to complete the order. ,in, The total time required for delivery person i. Let i be the number of deliveries that delivery person i can complete per unit of time. This represents the distance a delivery person takes from their current location to their destination. The number of tasks that delivery person i can handle simultaneously; based on the delivery time and packaging requirements of the dishes in the bulk orders, combined with whether the delivery person can handle small orders and the shortest time required for the delivery person to complete the orders, the dish combination of each small order is determined, and the bulk orders are split into small orders.

2. The method according to claim 1, wherein, The process of acquiring order data from various food delivery platforms through an integrated ordering system, constructing an order field mapping rule base, and converting the order data from various food delivery platforms into order data in a unified standard format includes: Order data from various food delivery platforms is obtained through the API interface of the integrated ordering system. This data includes customer order information and order cancellation requests. Customer order information includes order ID, customer information, menu list, price, merchant information, platform information, customer remarks, and order time. Order cancellation requests include the reason for cancellation, customer ID, platform information, order ID, and cancellation time. Field definitions from the order data of major food delivery platforms are obtained through the API interface of the integrated ordering system. Fields in the obtained order data are manually labeled, assigning each field a unique standardized identifier and a unified standard name. An order field mapping rule library is constructed to record the correspondence between different order fields across different platforms, and this library is updated regularly. Based on the obtained order data from various food delivery platforms, a multi-layered data parsing algorithm is used, according to the order field mapping rule library, to convert the order data from each platform into a unified standard format, and missing data is supplemented.

3. The method according to claim 1, wherein, The process involves using an order decoding module to decode and convert standard-format order data, transforming it into order data in a preset standard order data format for the integrated ordering system, and sending it to the merchant's integrated ordering system. This includes printing the order and real-time monitoring of the execution status and progress of each food preparation task, including: Based on the pre-set decoding rule set built into the integrated ordering system, the system obtains the original format definitions and decoding parameters of orders from various platforms. The decoding rule set includes different platform order formats, field names, field types, and platform-specific marking methods. Using the obtained decoding parameters, the order decoding module decodes the standard format order data and converts it into the integrated ordering system's pre-set standard order data format. Through a network interface, the converted order data is sent to the merchant's integrated ordering system, and the order is printed. The merchant's integrated ordering system receives and obtains the parsed and standardized order data. Based on the quantity, specifications, and customer remarks in the order, the task management module generates a food preparation task list. The system processes orders and executes food preparation tasks. Through the integrated ordering system's monitoring module, the execution status and progress of each food preparation task are monitored in real time, recording and displaying the progress. Based on real-time and historical monitoring data, the isolated forest algorithm is used to determine if there are delays in food preparation progress. If a step in the food preparation task fails to complete within the scheduled time, a long short-term memory network is used to train a model based on the real-time monitoring data to predict the completion time of the delayed task and trigger an abnormal progress alert. Delayed dishes are given priority processing, and the alert includes the delayed dish and its estimated completion time. If the food preparation task is completed, the order is marked as completed, and the order data is sent to the delivery system.

4. The method according to claim 1, wherein, The process of updating the delivery status of orders in real time through an integrated ordering system and pushing the latest delivery information to customers includes: The integrated ordering system obtains the delivery person's current location and feedback information in real time, updates the order's delivery status synchronously, and pushes the latest delivery information to customers. If a delivery abnormality occurs during the delivery process, the integrated ordering system sends a notification message to the merchant and customer until the delivery person reports that the order has been delivered. The order status is then updated to "completed". Delivery abnormalities include the delivery person failing to pick up the goods on time and the delivery route being inappropriate.

5. The method according to claim 1, wherein, The system obtains order status in real time through an integrated ordering system, identifies overdue orders and overdue stages, predicts overdue risks and stages based on order delivery and weather data, and sends overdue order warning information to merchants, delivery personnel, and customers, including: The integrated ordering system's real-time monitoring module acquires order status in real time and records it in the order monitoring database. Order status includes order creation, food preparation start, food preparation complete, delivery start, delivery in progress, and delivery complete. A push notification module sends notifications of each order status change to relevant merchants and customers. Based on the real-time updated order status, the integrated ordering system's anomaly detection module monitors orders. If an order times out at any stage, it is automatically marked as an overdue order, and the overdue stage is indicated. Historical order delivery data, including order status change records, delivery time, food preparation time, and delivery route, is obtained through the merchant's integrated ordering system and monitored in real time. The system provides real-time status updates for current orders; it also acquires historical workload data for each delivery person through the delivery person management module of the integrated ordering system, including the number of delivery tasks, the number of orders currently being handled, and delivery time; based on historical order delivery data, delivery person historical workload data, and historical weather data, and by labeling historical overdue orders and overdue stages, it uses a support vector machine algorithm to train a model and construct an order overdue prediction model to predict the overdue risk and overdue stage of the current order. Weather data includes temperature, wind speed, and rainfall; and based on the prediction results of orders with overdue risk, it sends order overdue warning information to merchants, delivery persons, and customers through the push notification module of the integrated ordering system.

6. The method according to claim 1, wherein, The process of determining whether a merchant agrees to a return or cancellation based on customer cancellation requests obtained from the food delivery platform, and synchronizing the merchant's confirmation information to the food delivery platform, includes: Based on customer order cancellation requests obtained from the food delivery platform, the data is converted using a pre-set standard data format of the integrated ordering system to obtain the converted standard data format for cancellation requests. This data includes the reason for cancellation, order ID, customer information, menu item list, quantity, and cancellation time. Based on the cancellation data received from the integrated ordering system, the system determines whether the merchant agrees to the return or cancellation. If the merchant agrees, a confirmation cancellation message is generated; if not, a rejection is recorded and a notification is sent. Finally, based on the merchant's confirmed return or cancellation information, the system synchronizes the merchant's confirmation information to the food delivery platform via the integrated ordering system's API interface.

Images