Multi-platform order delivery state synchronization method and system

Abstract

The invention relates to a multi-platform order delivery state synchronization method and system, and relates to the technical field of data synchronization. The method comprises the following steps: generating tasks based on a delivery order, automatically judging and screening out tasks allowed to be delivered by sequentially checking multi-dimensional strategy rules such as sales accounts, logistics channels and order attributes, marking the states of the tasks, and writing the states into a task pool; a task identifier to be processed is reliably obtained from the task pool through a timed task by adopting a batch query mechanism based on self-increasing primary key descending sorting and vernier anchor points, and the task identifier to be processed is written into a message queue, so that omission during dynamic data processing is avoided; and the task is consumed from the message queue, and according to the e-commerce platform to which the task belongs, a corresponding asynchronous bid issuing, incremental bid issuing or combined bid issuing strategy executor is called to adapt to the interface difference and service logic of different platforms, and the synchronization of the delivery state to the target platform is completed. According to the invention, efficient, accurate and reliable multi-platform order delivery state automatic synchronization is realized.

Description

Technical Field

[0001] This invention relates to a method and system for synchronizing order shipment status across multiple platforms, belonging to the field of data synchronization technology. Background Technology

[0002] With the booming development of cross-border e-commerce, businesses typically use Order Management Systems (OMS) to handle orders from multiple sales platforms such as Amazon, eBay, and independent websites. Automating the entire process from order receipt, warehousing and shipping to status synchronization is key to improving operational efficiency and ensuring customer experience. Accurately and promptly synchronizing the logistics status after shipment back to each sales platform is a core step in forming a fulfillment loop, completing platform settlements, and maintaining store performance, presenting significant technological challenges.

[0003] In existing technologies, there has been in-depth research on the automated processing of e-commerce orders. For example, Chinese invention patent application CN116823380A provides an automated method for processing e-commerce orders. This technical solution can efficiently receive orders from various platforms, intelligently filter out non-standard orders (such as orders with remarks or abnormal orders), parse order information, match and verify the delivery address with the local address database, and finally lock inventory and generate internal shipping instructions. The above technical solution effectively solves the automation problem in the first half of the order fulfillment process, namely, how to accurately and reliably transform multi-channel, heterogeneous order data into an executable shipping task for the internal warehouse. Its technical focus lies in the internal aggregation, cleaning, and transformation of data.

[0004] However, after the physical goods have left the warehouse, the latter half of the fulfillment process—namely, how to reverse and synchronously transmit the shipped status and logistics tracking information back to the various e-commerce platforms from which the order originated—faces a series of different technical challenges that the aforementioned order processing methods do not address and cannot solve. First, status synchronization is not a uniform operation for every shipment; it requires a multi-dimensional, strategic task generation and dispatch engine based on sales account permissions, logistics channel configuration, and order attributes (such as whether it's an FBA order) to achieve intelligent triggering and judgment. Second, different e-commerce platforms (such as Amazon, eBay, and independent websites) have fundamental differences in their interface specifications, data models, and business logic for status synchronization. For example, Amazon uses an asynchronous callback mechanism, independent websites need to support SKU-level incremental updates, and eBay requires full coverage of tracking numbers. This necessitates that the execution framework possess a high degree of platform heterogeneity adaptability. Finally, when interacting with external platform APIs on a large scale and at high frequency, the system needs to have industrial-grade robustness, including batch scheduling to prevent omissions in dynamic task pools, and refined intelligent fault tolerance, retry and circuit breaker management for network anomalies, interface rate limiting and various platform business errors.

[0005] In summary, existing technologies mainly focus on optimizing internal fulfillment processes. However, they do not provide a systematic solution for achieving highly reliable, adaptive, and complex order fulfillment status synchronization across multiple platforms. This means that this process still relies heavily on manual operation in actual operation or faces bottlenecks in efficiency, accuracy, and stability. There is an urgent need for an automated order fulfillment status synchronization method that can specifically address the above challenges, achieve high efficiency and accuracy, and adapt to the differences between multiple platforms. Summary of the Invention

[0006] To address the problems existing in the prior art, this invention proposes a method and system for synchronizing order delivery status across multiple platforms.

[0007] The technical solution of the present invention is as follows: On one hand, the present invention provides a method for synchronizing order shipment status across multiple platforms, comprising the following steps: Based on the sales order, a delivery task is generated. The delivery task is then determined to be allowed to be automatically dispatched according to a dispatch strategy that includes multiple quantifiable rules to be executed sequentially. When all rules are determined to be allowed, the delivery task status is marked as not dispatched and written to the task pool. Otherwise, it is marked as restricted from dispatching by the strategy and written to the task pool. The system queries the task pool for delivery tasks that are either undispatched or retryable. The system uses a query operation that combines descending sorting based on the auto-incrementing primary key of the task table with batch retrieval using a cursor to write the identifier of the queried delivery task into the message queue. Consume shipping tasks from the message queue, and execute the shipping dispatch action according to the corresponding dispatch strategy of the e-commerce platform to which the shipping task belongs, driving the sales order status of the target platform to synchronize with the shipped status; when the execution fails, parse the error information, and if the error reason belongs to the preset whitelist, update the task status to "failed and not retried", otherwise retry according to the retry strategy.

[0008] Preferably, the distribution strategy includes a sales account strategy, a logistics channel strategy, and an order attribute strategy. The conditions for determining whether automatic distribution is allowed are as follows: the sales account strategy determines that the corresponding sales account has enabled the automatic labeling function on the designated platform; the logistics channel strategy determines that the logistics channel used by the current sales order is allowed to be automatically labeled; and the order attribute strategy determines that the sales order status is neither canceled nor an FBA order.

[0009] Preferably, the query operation using descending sorting based on the auto-incrementing primary key of the task table combined with batch retrieval by cursor is as follows: Based on the triggering of the scheduled task and the status of the pending shipping tasks, fixed filtering conditions are determined for querying the task pool; an initial query is performed, and the record with the largest primary key value among the task records that currently meet the fixed filtering conditions is taken as the starting anchor point. Iterative queries are performed using a decreasing anchor point approach, with the smallest primary key value in the previous batch of query results used as the update anchor point for the next query in each query; an iterative query statement is constructed based on the update anchor point, and each query is limited to primary key values ​​less than the update anchor point, and a preset number of records are retrieved in descending order of primary key as the current batch of data.

[0010] Preferably, the corresponding delivery strategy is invoked based on the e-commerce platform to which the delivery task belongs, including: If the platform is Amazon, the call to the standard release interface will return immediately and mark the task as being in the standard release stage. The final processing result of this call can be queried asynchronously through a separate scheduled task. If the platform is an independent website platform, the total number of SKUs that have been marked is calculated by querying the historical successful marking records of the sales order item SKU corresponding to the delivery task. The minimum value of the difference between the current delivery quantity and the total order quantity minus the total number of marked items is taken as the actual number of products marked in this delivery. If the platform is eBay, query all tracking numbers of all uncancelled shipments under the same sales order, and submit a full list of tracking numbers in a single API call, covering the historical tracking number records of this sales order on the platform.

[0011] Preferably, the method further includes batch comparing the shipping status of the e-commerce platform with that of the system through independent timed data comparison tasks, and using a backoff strategy and a circuit breaker mechanism to handle interface call exceptions. The timed data comparison tasks are set with different execution frequencies according to the platform type; the backoff strategy is an exponential backoff strategy; and the circuit breaker mechanism is triggered when the interface call failure rate in a single comparison task exceeds a preset threshold.

[0012] Preferably, the whitelist is configured with the platform identifier as the key and the list of error keywords that do not need to be retried as the value; during matching, it is determined whether the error information returned from the platform contains any keyword in the keyword list; if the match is successful, it is determined to be a permanent failure that does not need to be retried.

[0013] Preferably, the retry strategy includes using exponential backoff retries for network timeouts or platform rate limiting errors; otherwise, using fixed-interval retries until the maximum number of retries is reached.

[0014] Preferably, in the bidding strategy for independent website platforms, if the calculated actual number of goods to be bid is 0, then the operation of only synchronizing the shipping tracking number information to the platform is performed.

[0015] Preferably, after the task identifier is written to the message queue, the corresponding message consumer loads the corresponding strategy class based on the platform type information carried in the message to execute the specific task assignment action.

[0016] On the other hand, the present invention also provides a multi-platform order shipment status synchronization system, the system comprising: The task generation and strategy judgment module is used to generate delivery tasks based on sales orders and determine whether automatic delivery of the delivery task is allowed according to a dispatch strategy containing multiple quantifiable rules to be executed sequentially. When all rules are determined to be allowed, the delivery task status is marked as not dispatched and written to the task pool; otherwise, it is marked as restricted from dispatching by the strategy and written to the task pool. The task query and batch delivery module is used to query the delivery tasks in the task pool whose status is undelivered or retryable through a scheduled task. The module uses a query operation based on the auto-incrementing primary key of the task table in descending order and a cursor to obtain the batches of the query operations to write the identifier of the queried delivery task into the message queue. The task execution and error handling module is used to consume shipping tasks from the message queue, execute the shipping dispatch action according to the corresponding standard dispatch strategy of the e-commerce platform to which the shipping task belongs, and drive the sales order status of the target platform to synchronize with the shipped status. When the execution fails, the error information is parsed. If the error reason belongs to the preset whitelist, the task status is updated to "failed and not retried". Otherwise, the retry is performed according to the retry strategy.

[0017] The present invention has the following beneficial effects: 1. This invention provides a method and system for synchronizing order delivery status across multiple platforms. By applying three quantifiable rules—sales account, logistics channel, and order attributes—to make strategy judgments before execution, the system only generates undelivered tasks when all rules pass. This intercepts invalid synchronization tasks caused by unauthorized accounts, disabled channels, or canceled / FBA orders from the source, significantly reducing invalid or erroneous platform API calls initiated due to non-compliance with business rules, and improving system resource utilization and processing accuracy. 2. This invention provides a method and system for synchronizing order shipment status across multiple platforms. By implementing three fundamentally different strategy executors for Amazon, independent websites, and eBay, respectively—asynchronous shipment, incremental shipment, and merged shipment—the system can adapt to the interface characteristics of each platform. For Amazon, the system immediately returns success and asynchronously polls the results after calling the interface, solving the throughput bottleneck caused by synchronous waiting and improving system response speed and processing capacity. For independent websites, the actual shipment quantity is determined by calculating the difference between the total order quantity and the historical shipment quantity in real time, achieving accurate incremental synchronization of shipments of the same order item (SKU) in multiple packages, improving the accuracy of inventory deduction and status tracking. For eBay, the system collects the tracking numbers of all non-cancelled shipment orders for each order, submits them all at once, and overwrites the historical records, solving the problem of scattered tracking numbers and chaotic platform display when the same order is shipped multiple times, and improving the centralization and manageability of order logistics information. 3. This invention provides a method and system for synchronizing order delivery status across multiple platforms. By employing a cursor-based query method that uses the auto-incrementing primary key of the task table in descending order and the current maximum ID as the anchor point, and uses the minimum ID of the previous batch as the new condition in batches, the method retrieves tasks to be processed from a dynamically growing task pool. This fundamentally avoids the data omission or duplicate processing problems that may occur when using traditional pagination queries (such as LIMIT offset, size) in scenarios where tasks are continuously written. It ensures that every task that meets the conditions can be accurately scheduled, improving the integrity and reliability of data processing. Attached Figure Description

[0018] Figure 1 This is a flowchart of the method of the present invention. Detailed Implementation

[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] It should be understood that the step numbers used in the text are for ease of description only and are not intended to limit the order in which the steps are performed.

[0021] It should be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0022] The terms “comprising” and “including” indicate the presence of the described feature, whole, step, operation, element and / or component, but do not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components and / or collections thereof.

[0023] The term “and / or” refers to any combination of one or more of the associated listed items, as well as all possible combinations, and includes these combinations.

[0024] Example 1: like Figure 1 As shown in the figure, this embodiment provides a method for synchronizing order shipment status across multiple platforms. The method includes: S1. Generate a delivery task based on the sales order. Determine whether the delivery task is allowed to be automatically dispatched according to the dispatch strategy containing multiple quantifiable rules to be executed sequentially. When all rules are determined to be allowed, the delivery task status is marked as not dispatched and written to the task pool. Otherwise, it is marked as restricted by the strategy and not dispatched and written to the task pool. In this embodiment, the distribution strategy includes a sales account strategy, a logistics channel strategy, and an order attribute strategy. The conditions for allowing automatic distribution are as follows: the sales account strategy determines that the corresponding sales account has enabled the automatic labeling function on the designated platform; the logistics channel strategy determines that the logistics channel used by the current sales order is allowed to be automatically labeled; and the order attribute strategy determines that the sales order status is neither canceled nor an FBA order. Specifically, in this embodiment, the sales account policy queries the sales_order_mark_account configuration table to check if the is_auto_mark field value of the specified sales account on the corresponding platform is 1. If it is 1, it indicates that the automatic labeling function is enabled. The logistics channel policy queries the sales_order_mark_channel configuration table based on the sales account ID to check if the is_allow_mark field value of the logistics channel used by the current shipment order is 1. If it is 1, it indicates that automatic labeling is allowed. The order attribute policy directly checks whether the sales order is in a canceled state or whether it is an FBA order. The above three quantifiable rules of dispatch strategy are binary judgment rules that are executed sequentially. Only when all of them pass, the system marks the delivery task status as undispatched (status value 0) and writes it into the task pool (i.e., the sales_order_mark table); when any strategy fails, the task status is marked as strategy-restricted not to be dispatched (status value 4), and is also written into the task pool. Preferably, in this embodiment, when the status value is 1, it indicates that the system has started to execute the dispatch operation, such as calling the API of a third-party logistics (3PL) to generate a waybill, or executing internal data processing logic. Status value 1 is an intermediate state, indicating that the task is being processed but the final result has not yet been obtained. When the status value is 2, it indicates that the system encountered a retrievable temporary error during the process of attempting automatic dispatch or asynchronous status polling, such as network timeout, interface rate limiting, or platform error return. At this time, the system will trigger the intelligent retry mechanism. When the status value is 3, it indicates that the system encountered a final failure when executing the automatic dispatch operation. This includes situations where the error persists after multiple automatic retries for a task with status 2, and the system marks it as a final failure requiring manual intervention; or when the dispatch error is a fundamental error returned by the platform (such as an invalid order number), and the error code is configured in the system's whitelist, the system will determine it as a failure that does not require retrying, thereby skipping the retry process and directly updating its status to 3 (dispatch failure, manual handling required).

[0025] S2. Query the delivery tasks in the task pool whose status is undispatched or retryable through a scheduled task, and write the identifier of the queried delivery task into the message queue by using a query operation based on the auto-incrementing primary key of the task table in descending order and obtaining the task in batches by cursor. The query operation is triggered by a scheduled task (e.g., once per hour). Its core principle is to avoid pagination omissions caused by dynamic data changes by using a descending sort based on the task table's auto-incrementing primary key combined with batch cursor retrieval. Specifically, the implementation is as follows: S21. Assemble fixed filtering conditions, such as status as not dispatched (0) or retryable (2), number of failures less than failure threshold 3, creation time within 10 days of order delivery days, etc., and sort them in descending order by primary key id; when querying for the first time, obtain the maximum primary key id that currently meets the fixed filtering conditions as the starting anchor point (i.e., last_max_id). S22. Use the statement SELECT id FROM ... WHERE id < {last_max_id} ORDER BY id DESC LIMIT {batch_size} for iterative querying. This is an SQL statement that performs a decreasing paginated query based on the anchor point (last_max_id) and the batch size (batch_size). Each time, the smallest primary key id in the previous batch query result is used as the last_max_id for the next query. This process is repeated in a decreasing manner until all records that meet the conditions have been processed. S23. Write the task identifier (primary key id) retrieved in each batch into the Kafka message queue one by one; Preferably, through the mechanism of steps S21-S23, even if new tasks are generated during the query process, the data of the already determined batch will not be affected.

[0026] S3. Consume shipping tasks from the message queue, and execute the shipping dispatch action according to the corresponding standard dispatch strategy of the e-commerce platform to which the shipping task belongs, driving the sales order status of the target platform to synchronize with the shipped status; when the execution fails, parse the error information, and if the error reason belongs to the preset whitelist, update the task status to "failed and not retried", otherwise retry according to the retry strategy. Among them, the corresponding dispatch strategy is invoked based on the e-commerce platform to which the delivery task belongs, including: If the platform is Amazon, the system will immediately return and mark the task as "submitting" after calling the SubmitFeed interface. The final processing result of the call will be queried asynchronously through a separate scheduled task. In this embodiment, after calling the SubmitFeed interface, the platform will immediately return a feedId. The system will bind and store the feedId with the task, update the task status to "submitting" and return success. Subsequently, the final processing status of the feedId will be obtained by polling the GetFeedSubmissionResult interface through a separate DIFF scheduled task. If the platform is an independent website platform, the total number of SKUs marked for shipment is calculated by cumulatively adding the historical successful marking records of the sales order item SKU corresponding to the shipment task. The minimum value of the difference between the current shipment quantity and the total order quantity minus the total number of marked shipments is taken as the actual number of goods marked for shipment, so as to realize the incremental synchronization of the same SKU in multiple shipments. Preferably, in the bidding strategy for independent website platforms, if the calculated actual number of goods to be bid is 0, then the operation of only synchronizing the shipping tracking number information to the platform is executed; If the platform is eBay, query all tracking numbers of all uncancelled shipments under the same sales order, and submit a full list of tracking numbers in a single API call to cover the historical tracking number records of this sales order on the platform; Preferably, after the task identifier is written to the message queue, the corresponding message consumer loads the corresponding strategy class based on the platform type information carried in the message to execute the specific task assignment action; When the above interface call fails, the system will parse the returned error code and error message, and trigger the intelligent retry and whitelist mechanism, specifically: Determine if the failure is due to a temporary fault such as network timeout. If so, proceed with the exponential backoff retry process. If not, match the error message with the preset whitelist configuration. The matching rule is that the error message text contains keywords configured in the whitelist. The whitelist is configured with the platform identifier as the key and a list of incorrect keywords that do not require retries as the value, for example: {"ebay": ["InvalidOrderId", "OrderIsCanceled"], "amazon": ["InvalidFeedId", "InternalError"]}; Among them, ebay and amazon are platform identifiers; InvalidOrderId is an invalid order ID; OrderIsCanceled means the order has been cancelled; InvalidFeedId is an invalid FeedID; InternalError means an internal error; During matching, it is determined whether the error information returned from the platform contains any keyword from the keyword list. If the match is successful, it is determined to be a permanent failure that does not require retrying, and the task status is directly updated to "failed to send without retry" and an alarm is issued. If the match is unsuccessful, it is determined to be a retryable business exception, and the task status is updated to "failed to send with retry", the failure count is incremented by 1, and the retry process is initiated. Preferably, in this embodiment, the system has a maximum retry threshold (e.g., 3 times). If the threshold is exceeded, the task is converted to a permanent failure. The retry strategy includes: For network timeout or platform rate-limiting errors (such as error code RequestThrottled), an exponential backoff strategy is adopted, waiting for 2^(maximum retry threshold) seconds before retrying; for other retryable errors, a fixed interval retry is adopted.

[0027] S4. Through independent timed data comparison tasks, batch compare the shipping status of e-commerce platforms with the shipping status of this system, and use backoff strategies and circuit breakers to handle interface call exceptions. The timed data comparison tasks are set with different execution frequencies according to the platform type. For example, the frequency is higher for Amazon platforms (e.g., once every 30 minutes) to specifically confirm the feedId status of asynchronous shipments; the frequency can be slightly lower for non-Amazon platforms (e.g., once per hour) as a fallback check. The backoff strategy is an exponential backoff strategy; the circuit breaker mechanism is triggered when the interface call failure rate exceeds a preset threshold in a single comparison task. To facilitate understanding, the batch comparison process for the timed data comparison task will be further explained, including: First, the system uses paginated SQL queries to batch read the order IDs or target task IDs to be compared from the task pool or order table. Then, it iterates through the batch of IDs and calls the platform's order details query interface one by one. To control the request rate, the system implements a token bucket rate limiting algorithm at the data access layer. Finally, the system compares the list of tracking numbers returned by the platform with the records in the local database. During the interface call process, if a network timeout or a 5xx error is encountered, the system uses an exponential backoff strategy to retry, waiting for 2 seconds initially, with the waiting time doubling for each subsequent attempt. At the same time, the system monitors the interface call failure rate within a single DIFF task. When the failure rate exceeds a preset threshold (e.g., 10%), a circuit breaker mechanism is triggered, suspending some requests and issuing an alarm.

[0028] Example 2: This embodiment provides a visualization processing system for SCD files of intelligent substations on mobile devices. The system includes: The task generation and strategy judgment module is used to generate delivery tasks based on sales orders and determine whether automatic delivery of the delivery task is allowed according to a dispatch strategy containing multiple quantifiable rules to be executed sequentially. When all rules are determined to be allowed, the delivery task status is marked as not dispatched and written to the task pool; otherwise, it is marked as restricted from dispatching by the strategy and written to the task pool. The task query and batch delivery module is used to query the delivery tasks in the task pool whose status is undelivered or retryable through a scheduled task. The module uses a query operation based on the auto-incrementing primary key of the task table in descending order and a cursor to obtain the batches of the query operations to write the identifier of the queried delivery task into the message queue. The task execution and error handling module is used to consume shipping tasks from the message queue, execute the shipping dispatch action according to the corresponding standard dispatch strategy of the e-commerce platform to which the shipping task belongs, and drive the sales order status of the target platform to synchronize with the shipped status. When the execution fails, the error information is parsed. If the error reason belongs to the preset whitelist, the task status is updated to "failed and not retried". Otherwise, the retry is performed according to the retry strategy.

[0029] It is worth noting that the system described in this invention and the method described in Embodiment 1 are based on the same inventive concept, and will not be repeated here.

[0030] In this application embodiment, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent the existence of A alone, A and B simultaneously, or B alone. A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" and similar expressions refer to any combination of these items, including any combination of singular or plural items. For example, at least one of a, b, and c can represent: a, b, c, a and b, a and c, b and c, or a and b and c, where a, b, and c can be single or multiple.

[0031] Those skilled in the art will recognize that the units and algorithm steps described in the embodiments disclosed herein can be implemented using electronic hardware, computer software, or a combination of electronic hardware and software. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0032] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0033] In the several embodiments provided in this application, any function, if implemented as a software functional unit and sold or used as an independent product, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, essentially, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0034] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent structural or procedural transformations made based on the content of the present invention's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for synchronizing order shipment status across multiple platforms, characterized in that, The method includes: Based on the sales order, a delivery task is generated. The delivery task is then determined to be allowed to be automatically dispatched according to a dispatch strategy that includes multiple quantifiable rules to be executed sequentially. When all rules are determined to be allowed, the delivery task status is marked as not dispatched and written to the task pool. Otherwise, it is marked as restricted from dispatching by the strategy and written to the task pool. The system queries the task pool for delivery tasks that are either undispatched or retryable. The system uses a query operation that combines descending sorting based on the auto-incrementing primary key of the task table with batch retrieval using a cursor to write the identifier of the queried delivery task into the message queue. Consume shipping tasks from the message queue, and execute the shipping dispatch action according to the corresponding dispatch strategy of the e-commerce platform to which the shipping task belongs, driving the sales order status of the target platform to synchronize with the shipped status; when the execution fails, parse the error information, and if the error reason belongs to the preset whitelist, update the task status to "failed and not retried", otherwise retry according to the retry strategy.

2. The method for synchronizing order shipment status across multiple platforms according to claim 1, characterized in that, The distribution strategy includes a sales account strategy, a logistics channel strategy, and an order attribute strategy. The conditions for allowing automatic distribution are as follows: the sales account strategy determines that the corresponding sales account has enabled the automatic labeling function on the designated platform; the logistics channel strategy determines that the logistics channel used by the current sales order is allowed to be automatically labeled; and the order attribute strategy determines that the sales order status is neither canceled nor an FBA order.

3. The method for synchronizing order shipment status across multiple platforms according to claim 1, characterized in that, The query operation, which uses descending sorting based on the auto-incrementing primary key of the task table combined with batch retrieval using a cursor, is as follows: Based on the triggering of the scheduled task and the status of the pending delivery task, the fixed filtering conditions for querying the task pool are determined; the first query is executed, and the record with the largest primary key value in the task record that currently meets the fixed filtering conditions is taken as the starting anchor point. The query is performed iteratively by decreasing the anchor point. Each time the query is performed, the smallest primary key value in the previous batch of query results is taken as the update anchor point for the next query. An iterative query statement is constructed based on the update anchor. Each query is limited to those whose primary key value is less than the update anchor, and a preset number of records are obtained as the current batch data in descending order of the primary key.

4. The method for synchronizing order shipment status across multiple platforms according to claim 1, characterized in that, The corresponding delivery strategy is applied based on the e-commerce platform to which the delivery task belongs, including: If the platform is Amazon, the call to the standard release interface will return immediately and mark the task as being in the standard release stage. The final processing result of this call can be queried asynchronously through a separate scheduled task. If the platform is an independent website platform, the total number of SKUs that have been marked is calculated by querying the historical successful marking records of the sales order item SKU corresponding to the delivery task. The minimum value of the difference between the current delivery quantity and the total order quantity minus the total number of marked items is taken as the actual number of products marked in this delivery. If the platform is eBay, query all tracking numbers of all uncancelled shipments under the same sales order, and submit a full list of tracking numbers in a single API call, covering the historical tracking number records of this sales order on the platform.

5. The method for synchronizing order shipment status across multiple platforms according to claim 1, characterized in that, The method also includes batch comparing the shipping status of e-commerce platforms with that of the system through independent timed data comparison tasks, and using a backoff strategy and a circuit breaker mechanism to handle interface call exceptions. The timed data comparison tasks are set with different execution frequencies according to the platform type; the backoff strategy is an exponential backoff strategy; and the circuit breaker mechanism is triggered when the interface call failure rate in a single comparison task exceeds a preset threshold.

6. The method for synchronizing order shipment status across multiple platforms according to claim 1, characterized in that, The whitelist is configured with the platform identifier as the key and the list of error keywords that do not need to be retried as the value. During matching, it is determined whether the error information returned from the platform contains any keyword in the keyword list. If the match is successful, it is determined to be a permanent failure that does not need to be retried.

7. A method for synchronizing order shipment status across multiple platforms according to claim 1 or 6, characterized in that, The retry strategy includes exponential backoff retries for network timeouts or platform rate limiting errors; otherwise, retries are performed at fixed intervals until the maximum number of retries is reached.

8. The method for synchronizing order shipment status across multiple platforms according to claim 4, characterized in that, In the bidding strategy for independent website platforms, if the calculated actual number of goods to be bid is 0, then only the shipping tracking number information is synchronized to the platform.

9. The method for synchronizing order shipment status across multiple platforms according to claim 1, characterized in that, After the task identifier is written to the message queue, the corresponding message consumer loads the corresponding strategy class based on the platform type information carried in the message to execute the specific task assignment action.

10. A multi-platform order shipment status synchronization system, characterized in that, The system includes: The task generation and strategy judgment module is used to generate delivery tasks based on sales orders and determine whether automatic delivery of the delivery task is allowed according to a dispatch strategy containing multiple quantifiable rules to be executed sequentially. When all rules are determined to be allowed, the delivery task status is marked as not dispatched and written to the task pool; otherwise, it is marked as restricted from dispatching by the strategy and written to the task pool. The task query and batch delivery module is used to query the delivery tasks in the task pool whose status is undelivered or retryable through a scheduled task. The module uses a query operation based on the auto-incrementing primary key of the task table in descending order and a cursor to obtain the batches of the query operations to write the identifier of the queried delivery task into the message queue. The task execution and error handling module is used to consume shipping tasks from the message queue, execute the shipping dispatch action according to the corresponding standard dispatch strategy of the e-commerce platform to which the shipping task belongs, and drive the sales order status of the target platform to synchronize with the shipped status. When the execution fails, the error information is parsed. If the error reason belongs to the preset whitelist, the task status is updated to "failed and not retried". Otherwise, the retry is performed according to the retry strategy.

Images