A method and system for order synchronization and anomaly identification based on a combination of primary key and time.

Abstract

This invention discloses a method and system for order synchronization and anomaly identification based on a combination of primary keys and time, comprising the following steps: S1, the cloud-based order access layer retrieves raw order data from at least one external e-commerce platform through a smart switching mechanism of message reception and timed fetching, and generates standardized orders with a unified data structure through field mapping and format conversion; S2, the cloud-based anomaly identification layer extracts the core features of the standardized orders to construct feature vectors, calls a rule engine to perform multi-dimensional parallel verification on the feature vectors, determines whether the standardized orders are abnormal orders based on the verification results, and generates a unique anomaly identifier (EOID) for orders determined to be abnormal; The beneficial effects of this invention are: This invention eliminates strong dependence on platform messages by constructing a two-layer order synchronization mechanism; it designs a two-layer cloud exit method of incremental ID query and time span query, which improves throughput and avoids data loss.

Description

Technical Field

[0001] This invention relates to the field of software engineering technology, specifically to a method and system for order synchronization and anomaly identification based on a combination of primary key and time. Background Technology

[0002] With the rapid development of the e-commerce industry, Enterprise Resource Planning (ERP) systems are increasingly widely used in order management. Currently, mainstream ERP systems primarily employ the following technical solutions when handling abnormal orders in their order management modules: At the system architecture level, most existing ERP systems are built using a Spring Cloud microservice architecture, while some still use the traditional monolithic architecture. Deployment is primarily single-tenant and independent, with only a few systems supporting multi-tenant logical isolation. Internally, modules mainly use RESTful APIs for synchronous data interaction, and basic order data is cached in in-memory databases such as Redis using Cache Aside and TTL expiration policies to improve read performance.

[0003] Regarding order synchronization and processing, existing technologies typically retrieve cross-platform order data using customized SDKs provided by various e-commerce platforms, with data transmission within the system using JSON format. After an order is integrated, the system performs serial hard-coded validation on order fields to verify the completeness and validity of the order information. For normal orders, the system synchronizes them from the cloud to the local ERP system's warehousing and finance modules via message queues or scheduled tasks. For abnormal orders, manual marking and classification are required, and the processing results are also manually entered and synchronized to the relevant business modules. Throughout the entire process, cross-module status synchronization mainly relies on interface pushes, lacking an automated closed-loop processing mechanism between business modules.

[0004] The aforementioned existing technical solutions have the following technical defects in practical applications: I. Low Order Synchronization Efficiency. Order and status synchronization heavily relies on platform push notifications. When the platform's push notification function is disabled, the system can only actively retrieve and update orders one by one via scheduled tasks. Furthermore, order field validation is performed serially using hard-coded methods, which cannot be processed in parallel. These mechanisms result in order recognition delays typically exceeding 10 seconds, and the system's single-machine throughput does not exceed 5000 orders / second, making it difficult to handle the order processing demands of high-concurrency scenarios such as major promotional events.

[0005] Second, order outbound processing carries the risk of order loss and has limited throughput. Normal order outbound processing relies on message queues or scheduled tasks. When message queues experience anomalies (such as message loss, backlog, or consumption failure), orders can be permanently lost, requiring manual intervention. Each manual intervention takes at least 5 minutes. In addition, time-based scheduled outbound processing has low throughput and is prone to system instability under high traffic surges.

[0006] Third, the mixed processing of abnormal and normal orders leads to inconsistent order statuses. In existing technologies, abnormal and normal orders are processed together in the same workflow. Invalid data generated by abnormal orders can easily mislead normal business processes. Even if some solutions attempt to separate the two, the separation logic is highly dependent on the execution order of the programs. If the execution order deviates, abnormal orders can easily be incorrectly processed as normal shipments. Actual verification shows that this type of solution results in an order status inconsistency error rate of no less than 1%, causing direct economic losses to both suppliers and sellers.

[0007] Fourth, manual processing is extremely inefficient. The workbench used for manually processing abnormal orders lacks real-time data synchronization capabilities. Operators must manually refresh the page to obtain the latest order status and processing results. Manual processing of a single abnormal order typically takes more than 5 minutes, severely dragging down the overall order processing efficiency. Furthermore, manual operation itself carries a high risk of misjudgment and omissions.

[0008] In summary, existing ERP systems have significant technical shortcomings in terms of order synchronization efficiency, accuracy of abnormal order identification, reliability of order cloud delivery, and efficiency of manual processing. To address these shortcomings, we propose a method and system for order synchronization and abnormal identification based on a combination of primary keys and time. Summary of the Invention

[0009] The purpose of this invention is to address the technical deficiencies of existing ERP systems in terms of order synchronization efficiency, abnormal order identification efficiency, and manual processing efficiency, and to provide an efficient method and system for order cloudification, abnormal order identification and processing, thereby achieving efficient automated processing of order cloudification and abnormal order identification.

[0010] To achieve the above objectives, a method for order synchronization and anomaly identification based on a combination of primary keys and time includes the following steps: S1, the cloud-based order access layer uses a smart switching mechanism between message reception and scheduled fetching to fetch raw order data from at least one external e-commerce platform. After field mapping and format conversion, it generates standardized orders with a unified data structure. S2. The cloud-based anomaly identification layer extracts the core features of the standardized order to construct a feature vector, calls the rule engine to perform multi-dimensional parallel verification on the feature vector, determines whether the standardized order is an abnormal order based on the verification results, and generates a unique anomaly identifier EOID for the orders determined to be abnormal. S3. For orders determined to be normal, the order cloud synchronization layer adopts a two-layer cloud strategy that combines incremental query based on the primary key ID of the data table with time span query based on the order creation time to synchronize normal order data to the local ERP system; for orders determined to be abnormal, their abnormal information is separated from normal orders for processing, preventing the abnormal orders from entering the normal fulfillment process. S4. The abnormal order processing layer performs layered processing based on the abnormal type and preset priority of the abnormal order, including order recovery, order locking, or pushing to the real-time interactive workbench for manual review, and performs data consistency verification on the processing results.

[0011] Preferably, the intelligent switching mechanism between message reception and timed fetching in step S1 specifically includes: The platform listens for order messages through a distributed message queue. When the message queue is healthy and the message backlog is less than a preset threshold, the order is received in real time using a message-driven mode. When the message queue is abnormal or the message backlog exceeds the preset threshold, the system automatically switches to a timed retrieval mode, which retrieves orders in batches over a time span by calling the platform's open API.

[0012] Preferably, step S2, which involves calling the rule engine for multi-dimensional parallel verification, specifically includes: The feature vector is distributed to multiple parallel computing nodes, and each node executes anomaly verification rules of different dimensions. The anomaly verification rules include anomaly verification of order amount, anomaly verification of delivery address, anomaly verification of product inventory, anomaly verification of buyer behavior, and anomaly verification of order timeliness. The rule engine supports hot reloading of rules, allowing for dynamic updates, additions, or deletions of validation rules without restarting the service. The updated rules take effect in real time for subsequent orders.

[0013] Preferably, the dual-layer cloud exit strategy in step S3 specifically includes a first layer of cloud exit and a second layer of cloud exit. The first layer of cloud exit performs incremental queries based on the auto-incrementing primary key ID of the data table. Each cloud exit task records the maximum primary key ID that has been processed. The next round of tasks continues to query from this maximum ID and pulls the newly added normal order data in batches. The second layer of cloud exit performs time span queries based on the order creation time. A preset time window is set to supplement the queries for orders that may have been missed by the first layer of cloud exit. The first and second cloud layers are executed in parallel, and the query results from both are deduplicated, merged, and then written into the local ERP system.

[0014] Preferably, the two-layer cloud exit strategy also includes an anomaly recovery mechanism: When a service outbound task is interrupted due to a network outage, the outbound task will be automatically restored from the last recorded primary key ID position and the time of interruption after restarting.

[0015] Preferably, step S4 also includes an intelligent order diversion mechanism for abnormal orders: The abnormal order's placement status is queried based on the EOID. If the abnormal order has not yet been placed into the warehousing or finance module, the subsequent fulfillment process for the order is terminated directly. If the abnormal order has been placed into the warehousing or finance module, the abnormal order information is pushed to the real-time interactive workbench in real time. The workbench displays the order details and the abnormal type simultaneously for reviewers to operate. The real-time interactive workbench maintains a long connection with the backend via WebSocket or polling.

[0016] Preferably, the data consistency verification in step S4 specifically includes: After abnormal orders are processed, the order status in the local ERP system is compared with the order status in the platform cloud service. The verification fields include at least the order status, payment status, logistics status, and inventory status. If the verification pass rate is lower than the preset threshold, an automatic rollback or alarm notification is triggered, and a consistency verification report is generated.

[0017] An order synchronization and anomaly identification system based on a combination of primary key and time includes an in-cloud order access layer, an in-cloud anomaly identification layer, an out-of-cloud order synchronization layer, and an anomaly order processing layer. The cloud-based order access layer is used to retrieve orders from external platforms through a smart switching mechanism of message reception and timed retrieval, and to standardize order data from different platform formats into a unified data structure. The cloud-based anomaly detection layer is used to extract the core features of standardized orders to construct feature vectors, perform multi-dimensional parallel verification through a rule engine to identify abnormal orders, and assign a unique identifier EOID to abnormal orders. The order cloud synchronization layer is used to execute a two-layer cloud exit strategy for normal orders, which combines incremental query based on primary key ID and query based on time span, and to perform diversion processing to prevent abnormal orders from exiting the cloud. The abnormal order processing layer is used to perform hierarchical processing according to the type and priority of the abnormality, and provides a real-time interactive workbench for manual review and processing of abnormal orders.

[0018] Compared with existing technologies, the beneficial effects of this invention are as follows: By constructing a two-layer order synchronization mechanism that intelligently switches between message reception and timed fetching, this invention eliminates the strong dependence of existing technologies on platform messages, significantly improving the stability and real-time performance of order access; by designing a two-layer cloud exit strategy that combines incremental primary key ID query and time span query, coupled with an anomaly recovery mechanism, it fundamentally solves the data loss problem caused by message queue anomalies, ensuring the integrity and reliability of order cloud exit; by using a rule engine for parallel verification and intelligent diversion processing of abnormal orders, it achieves decoupling processing of abnormal orders from normal orders, effectively reducing the risk of abnormal orders being erroneously fulfilled; by building a real-time data interaction workbench and supporting manual full-link synchronization, it greatly improves the efficiency of manual processing of abnormal orders and the timeliness of status correction; this invention realizes fully automated closed-loop control of the entire process of order access, identification, cloud exit to anomaly handling, significantly improving the overall processing efficiency and system stability of the ERP system in order management scenarios. Attached Figure Description

[0019] Figure 1 This is a block diagram of the overall architecture of the ERP system of the present invention; Figure 2 This is a flowchart illustrating the core business process for order and exception data processing in this invention. Figure 3 This is a timing diagram of the data model of the present invention; Figure 4 This is a schematic diagram of the internal structure of the module of the present invention. Detailed Implementation

[0020] 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.

[0021] Please see Figure 1-4 This invention provides a technical solution: a method for order synchronization and anomaly identification based on a combination of primary key and time, comprising the following steps: S1. The cloud-based order access layer uses a smart switching mechanism between message reception and scheduled data retrieval to retrieve raw order data from at least one external e-commerce platform. After field mapping and format conversion, standardized orders with a unified data structure are generated. The smart switching mechanism between message reception and scheduled data retrieval specifically includes: The platform listens for order messages through a distributed message queue. When the message queue is healthy and the message backlog is less than a preset threshold, the order is received in real time using a message-driven mode. When the message queue is abnormal or the message backlog exceeds the preset threshold, the system automatically switches to a timed retrieval mode, which retrieves orders in batches over a time span by calling the platform's open API.

[0022] S2. The cloud-based anomaly detection layer extracts the core features of standardized orders to construct feature vectors. It then calls the rule engine to perform multi-dimensional parallel verification on these feature vectors. Based on the verification results, it determines whether a standardized order is an anomaly and generates a unique anomaly identifier (EOID) for each anomaly. The multi-dimensional parallel verification using the rule engine specifically includes: The feature vectors are distributed to multiple parallel computing nodes, and each node executes different anomaly verification rules. The anomaly verification rules include anomaly verification of order amount, anomaly verification of delivery address, anomaly verification of product inventory, anomaly verification of buyer behavior, and anomaly verification of order timeliness. The rules engine supports hot reloading of rules, allowing for dynamic updates, additions, or deletions of validation rules without restarting the service. Updated rules take effect in real time for subsequent orders.

[0023] S3. For orders deemed normal, the order cloud synchronization layer adopts a two-layer cloud exit strategy that combines incremental queries based on the primary key ID of the data table with time span queries based on the order creation time to synchronize normal order data to the local ERP system. For orders deemed abnormal, their abnormal information is separated from normal orders to prevent abnormal orders from entering the normal fulfillment process. The two-layer cloud exit strategy specifically includes a first-layer cloud exit and a second-layer cloud exit. The first layer of cloud access performs incremental queries based on the auto-incrementing primary key ID of the data table. Each cloud access task records the maximum primary key ID that has been processed. The next round of tasks continues to query from this maximum ID and pulls the newly added normal order data in batches. The second layer of cloud access performs time span queries based on the order creation time. A preset time window is set to supplement the queries for orders that may have been missed by the first layer of cloud access. The first and second layers of cloud exit are executed in parallel, and the query results of the two are deduplicated, merged, and written into the local ERP system. The two-layer cloud exit strategy also includes an anomaly recovery mechanism: When a service outbound task is interrupted due to a network outage, the outbound task will be automatically restored from the last recorded primary key ID position and the time of interruption after restarting.

[0024] S4, the abnormal order processing layer, performs tiered processing based on the abnormal order type and preset priority, including order recovery, order locking, or pushing to the real-time interactive workbench for manual review, and verifies the data consistency of the processing results; it also includes an intelligent abnormal order triage mechanism: The status of abnormal orders is queried based on EOID. If the abnormal order has not yet been assigned to the warehousing or finance module, the subsequent fulfillment process of the order will be terminated directly. If the abnormal order has been assigned to the warehousing or finance module, the abnormal order information will be pushed to the real-time interactive workbench in real time. The workbench will display the order details and the type of abnormality for the reviewers to operate. The real-time interactive workbench maintains a long connection with the backend via WebSocket or polling. Data consistency verification specifically includes: After abnormal orders are processed, the order status in the local ERP system is compared with the order status in the platform cloud service. The verification fields include at least the order status, payment status, logistics status, and inventory status. If the verification pass rate is lower than the preset threshold, an automatic rollback or alarm notification is triggered, and a consistency verification report is generated.

[0025] It should be noted that, in this embodiment, the system is deployed in the following hardware environment: a distributed deployment using 7 cloud servers (8 CPU cores, 16GB memory, 100GB ESSD hard drive), and a master-slave cluster consisting of 2 MySQL 5.7 database servers. The network environment is a 100Mbps fiber optic connection with dual public / internal network links, network latency ≤5ms, and supports elastic bandwidth expansion. Peripherals include warehouse barcode scanners and waybill printers, supporting real-time serial communication with a data transmission rate ≥1Mbps.

[0026] In terms of software environment, the operating system is CentOS 7.9 64-bit; the development framework is Spring CloudAlibaba 2021.0.5.0; the front-end workbench uses Vue3; the middleware includes RocketMQ 4.9.4, Redis 6.0, and Nginx 1.24; and the database uses MySQL 5.7 master-slave architecture.

[0027] In use, in step S1, the system retrieves raw order data from at least one external e-commerce platform through a smart switching mechanism that switches between message reception and timed fetching.

[0028] Specifically, the system starts in message-driven mode by default, using RocketMQ to monitor order messages from various platforms in real time. Simultaneously, a daemon thread checks the service health and message backlog of RocketMQ every 10 seconds. When a RocketMQ connection timeout or message backlog exceeds a preset threshold (e.g., 10,000 messages) is detected, the daemon thread triggers a switch signal, and the system automatically switches to scheduled retrieval mode in the next retrieval cycle. In scheduled retrieval mode, the system calls the order query API of each platform, retrieving orders in batches every 5 minutes (the query range is 5 minutes before the current time to the current time).

[0029] After the original order data is retrieved, the system performs a standardized transformation. Taking the Taobao platform as an example, the original order data is in JSON format and includes fields such as "tid" (order number), "payment" (actual payment amount), and "receiver_state" (receiving province).

[0030] The system executes mapping logic based on a predefined field mapping table: mapping "tid" to "platformOrderId", multiplying "payment" by 100 (yuan to cent conversion) to "totalAmount", and concatenating "receiver_state" + "receiver_city" + "receiver_district" to "deliveryAddress". Regarding format conversion, the time field "created" remains unchanged from its original format of "2026-01-17 14:30:25", but the time zone is standardized to UTC+8. After standardization, a standardized order with a unified data structure is generated.

[0031] In this step, the field mapping matching degree is ≥99.9%, and the order access delay is ≤1 second. After standardization is completed, normal orders enter the fulfillment process, and standardized orders and their original exception messages are pushed to step S2.

[0032] In step S2, after the standardized order pushed in step S1 arrives, the system extracts the core features of the standardized order to construct a feature vector, and calls the rule engine to perform multi-dimensional parallel verification of the feature vector.

[0033] The feature vector construction process involves the system extracting 11 core fields from standardized orders, including “platformOrderId”, “totalAmount”, “productQuantity”, “deliveryAddress”, “buyerId”, “createTime”, “payTime”, “skuld”, “storeld”, “productPrice”, and “inventory”, and concatenating them into a one-dimensional feature vector in a preset order. After receiving the feature vector, the rule engine broadcasts the feature vector to two parallel computing nodes. Node 1 performs verification of the amount dimension and the timeliness dimension; Node 2 performs verification of the address dimension, the inventory dimension, and the behavior dimension. Each node runs independently and without blocking.

[0034] Taking the amount-based verification as an example, the system queries the store's historical orders over the past 30 days and calculates the average order value. and standard deviation If the total amount of the current order is greater than +3 Or the total amount of the current order is less than the listed price of the product. quantity If the value is 0.5, the amount dimension is considered abnormal; after each node completes the verification, the result is sent back to the rule engine aggregation node.

[0035] If any dimension's verification result is abnormal, the order is determined to be an abnormal order. The system generates an EOID for the abnormal order, associates the EOID with the abnormal information, stores it in Redis (caching layer, TTL=7 days) and MySQL (persistence layer), and pushes it to step S3.

[0036] In step S3, the orders output in step S2 are divided into two categories: normal orders and abnormal orders. This step performs a sorting process for the two types of orders.

[0037] For normal orders, the system executes a two-layer cloud exit strategy. After two threads execute in parallel, the query results are deduplicated using "id" as the key value. The deduplicated order data is then written in batches to the order master table and the warehousing and finance modules of the local ERP system.

[0038] For abnormal orders, the system does not perform the above-mentioned cloud exit operation. Instead, it diverts and forwards the abnormal order's EOID and abnormal information to step S4, and marks the order status in the local ERP system as "abnormal pending processing" to prevent it from being shipped normally.

[0039] In step S4, after the abnormal orders from step S3 arrive, the system performs tiered processing. The system first queries the distribution status of the abnormal order in the warehousing and finance modules based on the EOID: If the order status is "pending review" (not yet issued), the system will directly update the order status to "abnormal termination", release the occupied inventory, record the processing log, and end the process; If the order status is "allocated to warehouse", "allocated to finance", or "partially shipped", the system will push the order to the real-time interactive workbench according to the exception type and EOID.

[0040] After receiving a new abnormal order via WebSocket, the real-time interactive workbench displays the order in the "Pending" list on the interface. The workbench displays the abnormal orders in order of priority: "Paid and Pending Shipment" abnormal orders (priority 1, marked in red) are at the top; "Shipped and in Transit" abnormal orders (priority 2, marked in orange) are next; "Delivered" abnormal orders (priority 3, marked in yellow) are third; and "Unpaid" abnormal orders (priority 4, marked in gray) are at the bottom.

[0041] After reviewing the details of the abnormal order, the auditor performs the operation. Taking an order with an abnormality type of "inventory abnormality" as an example, if the auditor finds that the actual inventory is sufficient for shipment and determines that it is a misjudgment, then clicks the "Restore to Normal Order" button. The system responds to this operation by moving the order from the abnormal order table to the normal order table, triggering the re-execution of step S3, the cloud exit operation.

[0042] If the auditor confirms that the inventory is indeed insufficient, they will click the "Lock Order" button. The system will respond by sending a "Stop Shipping" command to the warehousing module (via RocketMQ message), a "Pause Settlement" command to the finance module, updating the order status to "Abnormal Lock," and recording the auditor, operation time, and processing opinion.

[0043] After all operations are completed, the system automatically performs a data consistency check. Taking the above-mentioned anomaly recovery operation as an example, the system compares the order status in the local ERP order master table (which is "Pending Shipment" after recovery) with the order status in the Taobao platform cloud service (which is also "Pending Shipment"), the payment status (both are "Paid"), and the inventory status (both occupy 1 item). All are consistent, and the check passes.

[0044] Actual testing showed that this invention was used to process 10,000 mixed orders (including 1,000 abnormal orders). The results were as follows: 999 abnormal orders were identified, with an accuracy rate of 99.9%; 9,852 orders were processed automatically, and 148 orders were processed manually, with an automatic processing rate of 98%; there were 0 orders with inconsistent data, with an inconsistency error rate of 0.05%; the average identification delay was 2.1 seconds; and the manual processing time for a single abnormal order was reduced from ≥5 minutes in the traditional method to ≤1 minute.

[0045] An order synchronization and anomaly identification system based on a combination of primary key and time includes an in-cloud order access layer, an in-cloud anomaly identification layer, an out-of-cloud order synchronization layer, and an anomaly order processing layer. The cloud-based order access layer is used to retrieve orders from external platforms through a smart switching mechanism that combines message reception and scheduled fetching, and to standardize order data from different platform formats into a unified data structure.

[0046] It should be noted that in this embodiment, the cloud-based order access layer listens for order messages pushed by various platforms via RocketMQ. When the RocketMQ service is healthy and the message backlog is less than a preset threshold, the system uses a message-driven mode to receive orders in real time, with access latency controlled within 1 second. When the RocketMQ service malfunctions or the message backlog exceeds the preset threshold, the system automatically switches to a scheduled retrieval mode. By calling the order query API of each platform, it retrieves order data in batches according to a preset time span (e.g., retrieval every 5 minutes, with the time window being orders created within the previous 5 minutes). The switching between the two modes is implemented using a hot-reload method, ensuring that the order access service is not interrupted during the switching process.

[0047] For orders received via messages, the cloud-based order access layer employs a two-step processing strategy: first, the order status is changed to "pending synchronization" to prevent the order from being incorrectly removed from the cloud under abnormal circumstances; then, the order message is parsed, the core fields of the order are extracted, and abnormal message information is saved separately for subsequent traceability. The saving operation of the abnormal message information is executed asynchronously with the standardized order processing to ensure that the recognition rate of abnormal messages is not affected by the main process.

[0048] The cloud-based order access layer performs standardization transformation on the raw order data pulled from various platforms. Specifically, this includes: mapping order fields from different platforms to the system's internal standard data model using a predefined field mapping table (e.g., mapping the "tid" field from Taobao to "platformOrderId" in this system, and mapping the "orderTotal" field from JD.com to "totalAmount" in this system); and performing format conversion. After standardization, standardized orders with a unified data structure are generated, with a field mapping matching degree ≥99.9%. Normal orders are pushed to the fulfillment process, while the standardized orders and their abnormal messages are pushed to the cloud-based anomaly identification layer.

[0049] The order outbound synchronization layer is used to implement a two-layer outbound strategy for normal orders, which combines incremental queries based on primary key IDs and queries based on time spans, and to perform diversion processing to prevent abnormal orders from leaving the cloud.

[0050] It should be noted that, in this embodiment, the order cloud synchronization layer includes an ID incremental cloud exit unit, a time span cloud exit unit, a traffic diversion control unit, and a status repair unit; The ID incremental cloud exit unit is used to perform incremental query cloud exit operations based on the auto-incrementing primary key ID of the data table for orders that are determined to be normal: maintain a cloud exit progress record table to record the maximum primary key ID that has been processed in each cloud exit task. When each round of cloud exit tasks starts, the maximum primary key ID is read from the progress record table. Starting from this ID, the newly added normal order data is queried in batches. After each batch of queries is completed, the maximum ID of the current batch is updated to the progress record table and the transaction is committed until all newly added orders have been queried. The Time Span Cloud Outgoing Unit is used to perform time span query cloud outgoing operations based on order creation time in parallel with the ID Incremental Cloud Outgoing Unit. It uses the current system time as a reference, sets query conditions that include a preset time window, queries normal order data created within that time window, and supplements orders missed by the ID Incremental Cloud Outgoing Unit due to primary key ID skipping or data delay writing. The query results and the query results of the ID Incremental Cloud Outgoing Unit are deduplicated and merged with the primary key ID as the key value before being written in batches to the local ERP system. The diversion control unit is used to receive abnormal order information carrying EOID pushed by the abnormal marking unit, identify abnormal orders according to EOID and perform diversion processing with normal orders, prevent abnormal orders from entering the normal fulfillment process, and at the same time route and forward the EOID and abnormal information of abnormal orders to the abnormal order processing layer, and mark the status of the corresponding order in the local ERP system as abnormal pending processing status. The status repair unit is used to respond to status repair instructions triggered by the real-time interactive workbench or the upper-level system, and to perform status repair operations on orders marked as abnormal pending status by the diversion control unit. This includes restoring the status of orders that were mistakenly judged as abnormal to normal and resubmitting them to the ID incremental cloud delivery unit and the time span cloud delivery unit for cloud delivery, as well as synchronously updating the status of confirmed abnormal orders to the final processing status.

[0051] The cloud-based anomaly detection layer is used to extract the core features of standardized orders to construct feature vectors. It then uses a rule engine to perform multi-dimensional parallel verification to identify abnormal orders and assigns a unique identifier (EOID) to each abnormal order.

[0052] It should be noted that, in this embodiment, the cloud-based order access layer includes a feature extraction unit, a vector construction unit, a rule engine unit, and an anomaly marking unit; The feature extraction unit is used to receive standardized orders pushed by the cloud order access layer and extract core feature information from the standardized orders according to preset dimensions. The core feature information includes at least the order amount, product quantity, structured information of the delivery address, buyer account identifier, order timestamp, payment timestamp, product SKU identifier, store identifier, and real-time inventory data. The vector construction unit receives the core feature information output by the feature extraction unit, performs numerical encoding and normalization of the features in each dimension according to a preset order, concatenates them to generate a one-dimensional feature vector in a unified format, and encapsulates the feature vector in a JSON data structure before outputting it to the rule engine unit. The rule engine unit receives feature vectors output by the vector construction unit and broadcasts these feature vectors to multiple parallel computing nodes. Each parallel computing node loads anomaly verification rules for different dimensions and performs parallel verification calculations. The anomaly verification rules include anomaly verification for order amount, delivery address, product inventory, buyer behavior, and order timeliness. The rule engine unit performs a logical OR operation on the verification results returned by each node and summarizes them. If any dimension's verification result is anomaly, the current order is determined to be an abnormal order. The rule engine unit also supports hot rule reloading. By listening to rule file change events in the configuration center, it dynamically updates the verification rules without restarting the service and makes the updated rules take effect immediately for subsequent orders. The anomaly marking unit is used to receive the judgment results of the rule engine unit, generate a unique anomaly identifier EOID for orders judged as abnormal according to the preset coding rules. The EOID is composed of the platform order number, system timestamp and random number combination. The EOID, the corresponding anomaly type code, the trigger rule ID and the verification timestamp are associated and written into the cache database and the persistent database. At the same time, the abnormal order information carrying the EOID is pushed to the order cloud synchronization layer.

[0053] The abnormal order processing layer is used to perform hierarchical processing based on the type and priority of the abnormality, and provides a real-time interactive workbench for manual review and processing of abnormal orders.

[0054] It should be noted that, in this embodiment, the abnormal order processing layer includes an abnormal locking unit, an automatic processing unit, a manual review unit, and a status write-back unit; The abnormal locking unit is used to receive abnormal orders forwarded by the diversion control unit, query the placement status of the abnormal order in the warehousing module and the financial module according to the EOID of the abnormal order, and if the query confirms that the abnormal order has not been placed in the warehousing module or the financial module, the subsequent fulfillment process of the abnormal order is terminated directly, the inventory resources occupied by the order are locked, and the order status is updated to abnormal termination status to block the path of being incorrectly shipped. The automatic processing unit is used to automatically handle abnormal orders that have been assigned to the warehousing or finance modules according to preset automatic processing rules: it matches the abnormal order type code with the preset processing strategy library, and automatically executes inventory rollback, order cancellation or refund triggering operations for abnormal orders that match successfully, without manual intervention; for abnormal orders that cannot match the preset strategy, it packages the abnormal order's EOID, order details, abnormal type and processing suggestions and pushes them to the manual review unit. The manual review unit is used to receive abnormal orders that require manual intervention from the automatic processing unit. It maintains a long connection with the real-time interactive workbench via WebSocket or polling, and pushes abnormal order information to the workbench for display in real time. The workbench sorts and groups abnormal orders according to their abnormality type and preset priority, and responds to operation instructions triggered by the reviewers on the workbench to perform manual processing operations, including order recovery, order locking, and abnormal rejection. The status write-back unit is used to write back the status of the processing result to the order master table, warehouse module, and financial module of the local ERP system after the abnormal order processing operation is completed in the abnormal locking unit, automatic processing unit, and manual review unit. At the same time, the processing result is synchronized to the corresponding platform cloud service through interface push, completing the status closed loop synchronization of the entire abnormal order processing process, and recording complete processing logs for subsequent audit traceability.

[0055] In summary: This invention eliminates strong dependence on platform messages by constructing a two-layer order synchronization mechanism; it designs a two-layer cloud-based approach of incremental ID query + time span query to improve throughput and avoid data loss; it achieves separate processing of order and abnormal information, with abnormal orders not being entered into the database; and it builds a real-time interactive processing workbench, combined with distributed parallel processing, to achieve efficient order synchronization and fully automated processing of abnormal orders.

[0056] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method for order synchronization and anomaly identification based on a combination of primary key and time, characterized in that, Includes the following steps: S1, the cloud-based order access layer uses a smart switching mechanism between message reception and scheduled fetching to fetch raw order data from at least one external e-commerce platform. After field mapping and format conversion, it generates standardized orders with a unified data structure. S2. The cloud-based anomaly identification layer extracts the core features of the standardized order to construct a feature vector, calls the rule engine to perform multi-dimensional parallel verification on the feature vector, determines whether the standardized order is an abnormal order based on the verification results, and generates a unique anomaly identifier EOID for the orders determined to be abnormal. S3. For orders that are determined to be normal, the order cloud synchronization layer adopts a two-layer cloud synchronization strategy that combines incremental query based on the primary key ID of the data table and query based on the time span of the order creation time to synchronize normal order data to the local ERP system. For orders deemed abnormal, their abnormal information is separated from that of normal orders to prevent the abnormal orders from entering the normal fulfillment process; S4. The abnormal order processing layer performs layered processing based on the abnormal type and preset priority of the abnormal order, including order recovery, order locking, or pushing to the real-time interactive workbench for manual review, and performs data consistency verification on the processing results.

2. The order synchronization and anomaly identification method based on a combination of primary key and time as described in claim 1, characterized in that, The intelligent switching mechanism between message reception and timed fetching in step S1 specifically includes: The platform listens for order messages through a distributed message queue. When the message queue is healthy and the message backlog is less than a preset threshold, the order is received in real time using a message-driven mode. When the message queue is abnormal or the message backlog exceeds the preset threshold, the system automatically switches to a timed retrieval mode, which retrieves orders in batches over a time span by calling the platform's open API.

3. The order synchronization and anomaly identification method based on a combination of primary key and time as described in claim 1, characterized in that, The step S2, which involves calling the rule engine for multi-dimensional parallel verification, specifically includes: The feature vector is distributed to multiple parallel computing nodes, and each node executes anomaly verification rules of different dimensions. The anomaly verification rules include anomaly verification of order amount, anomaly verification of delivery address, anomaly verification of product inventory, anomaly verification of buyer behavior, and anomaly verification of order timeliness. The rule engine supports hot reloading of rules, allowing for dynamic updates, additions, or deletions of validation rules without restarting the service. The updated rules take effect in real time for subsequent orders.

4. The order synchronization and anomaly identification method based on a combination of primary key and time as described in claim 1, characterized in that, The dual-layer cloud exit strategy in step S3 specifically includes a first layer of cloud exit and a second layer of cloud exit. The first layer of cloud exit performs incremental queries based on the auto-incrementing primary key ID of the data table. Each cloud exit task records the maximum primary key ID that has been processed. The next round of tasks continues to query from this maximum ID and pulls the newly added normal order data in batches. The second layer of cloud exit performs time span queries based on the order creation time. A preset time window is set to supplement the queries for orders that may have been missed by the first layer of cloud exit. The first and second cloud layers are executed in parallel, and the query results from both are deduplicated, merged, and then written into the local ERP system.

5. The order synchronization and anomaly identification method based on a combination of primary key and time as described in claim 4, characterized in that, The two-layer cloud exit strategy also includes an anomaly recovery mechanism: When a service outbound task is interrupted due to a network outage, the outbound task will be automatically restored from the last recorded primary key ID position and the time of interruption after restarting.

6. The order synchronization and anomaly identification method based on a combination of primary key and time as described in claim 1, characterized in that, Step S4 also includes an intelligent order diversion mechanism for abnormal orders: The abnormal order is queried based on the EOID. If the abnormal order has not yet been assigned to the warehousing or finance module, the subsequent fulfillment process of the order will be terminated directly. If the abnormal order has been assigned to the warehousing or finance module, the abnormal order information is pushed to the real-time interactive workbench in real time. The workbench displays the order details and the type of abnormality simultaneously for the reviewers to operate. The real-time interactive workbench maintains a long connection with the backend via WebSocket or polling.

7. The order synchronization and anomaly identification method based on a combination of primary key and time as described in claim 1, characterized in that, The data consistency verification in step S4 specifically includes: After abnormal orders are processed, the order status in the local ERP system is compared with the order status in the platform cloud service. The verification fields include at least the order status, payment status, logistics status, and inventory status. If the verification pass rate is lower than the preset threshold, an automatic rollback or alarm notification is triggered, and a consistency verification report is generated.

8. A system for order synchronization and anomaly identification based on a combination of primary key and time, characterized in that, This includes the cloud-based order access layer, the cloud-based anomaly identification layer, the cloud-based order synchronization layer, and the anomaly order processing layer. The cloud-based order access layer is used to retrieve orders from external platforms through a smart switching mechanism of message reception and timed retrieval, and to standardize order data from different platform formats into a unified data structure. The cloud-based anomaly detection layer is used to extract the core features of standardized orders to construct feature vectors, perform multi-dimensional parallel verification through a rule engine to identify abnormal orders, and assign a unique identifier EOID to abnormal orders. The order cloud synchronization layer is used to execute a two-layer cloud exit strategy for normal orders, which combines incremental query based on primary key ID and query based on time span, and to perform diversion processing to prevent abnormal orders from exiting the cloud. The abnormal order processing layer is used to perform hierarchical processing according to the type and priority of the abnormality, and provides a real-time interactive workbench for manual review and processing of abnormal orders.

Images