Jushuitan and Kingdee Cloud Galaxy Sales Order Integration: Middleware-Based E-commerce to ERP Data Sync Architecture

Scenario and Value

In e-commerce retail operations, order data is typically distributed across two systems: an e-commerce ERP and a backend ERP. One retail enterprise uses Jushuitan to manage online store orders, inventory, and after-sales records, while relying on Kingdee Cloud Galaxy as the backend financial and supply chain ERP. The two systems differ in data models, organizational structures, and code systems. Manual entry cannot meet real-time requirements and frequently causes document errors due to inconsistent coding.

This solution addresses the sales order synchronization scenario. By introducing a middleware hub to host master data and code mappings, sales deliveries from Jushuitan are transformed into sales orders in Kingdee Cloud Galaxy, and after-sales records are transformed into return notices. The solution covers both Qimen (for Taobao/Tmall stores) and non-Qimen (for multi-store and private domain) channels, orchestrating 9 policies in total. It is suitable for ETL or data synchronization platforms deployed in private environments.

Integration Architecture and Data Flow

The architecture consists of three system types: Jushuitan (including the Qimen interface), Kingdee Cloud Galaxy, and the integration platform hub. The hub acts as a middleware layer responsible for master data collection, code mapping maintenance, and document lookup support, avoiding direct coupling between the two end systems.

Data flow can be summarized in two phases. The first phase is master data synchronization: Kingdee Cloud Galaxy unidirectionally outputs four types of master data—materials, warehouses, customers, and sales deliveries—to the hub, serving as the reference baseline for subsequent business documents. The second phase is business document writing: Jushuitan sales deliveries are written into Kingdee sales orders by channel, and after-sales records are written into return notices by channel. Since the inventory organization and return customer on a return notice must be determined by looking up the original sales delivery, a dependency exists on the delivery data cached in master data.

The middleware hub plays four key roles: first, centrally maintaining four types of code mapping tables (material, customer, sales organization, and delivery); second, caching the delivery data required for lookups by return policies; third, serving as the execution point for code conversion, avoiding repeated mapping logic in business policies; fourth, providing independent query capabilities so that master data and business documents can be scheduled separately.

Interface List

The solution orchestrates 9 policies, classified by phase and synchronization direction as follows:

Master data query phase (the hub is the declared target but performs a no-op write, used only for caching):

• Policy 1: Kingdee material → Hub, FormId BD_MATERIAL, filtering by use organization and inventory organization
• Policy 2: Kingdee warehouse → Hub, FormId BD_STOCK, incremental by approval date
• Policy 3: Kingdee customer → Hub, FormId BD_Customer, filtering by the custom field that marks associated stores
• Policy 4: Kingdee sales delivery → Hub, FormId SAL_OUTSTOCK, filtering where the Jushuitan order number is non-empty

Sales order writing phase:

• Policy 5: Jushuitan Qimen sales delivery → Kingdee sales order (Taobao/Tmall stores)
• Policy 6: Jushuitan sales delivery → Kingdee sales order (non-Qimen, differential test scenario)
• Policy 7: Jushuitan sales delivery → Kingdee sales order (non-Qimen, private domain store)

Return notice writing phase:

• Policy 8: Jushuitan Qimen after-sales → Kingdee return notice
• Policy 9: Jushuitan after-sales → Kingdee return notice (non-Qimen)

All business policies depend on material, customer, and sales organization mappings. Policies 8 and 9 additionally depend on the sales deliveries cached by Policy 4, used to look up inventory organization and return customer.

Implementation Points

Code mappings must be configured before the policies are executed for the first time. Material mapping uses Kingdee FNumber as the source key and Jushuitan sku_id as the target key. Customer mapping uses Jushuitan shop_id as the source key and Kingdee FNumber as the target key, linked through the custom field F_SGT_Text. Sales organization mapping also uses shop_id as the source key, corresponding to Kingdee FSaleOrgId. Inventory organization and return customer mapping uses raw_so_id + sku_id as the source key, populating FOwnerIdHead_FNumber and FCustomerID_FNumber after looking up Policy 4's cached delivery data.

Qimen and non-Qimen channels require split processing. Taobao/Tmall stores use the Jushuitan Qimen interface, corresponding to Policies 5 and 8. Non-Taobao multi-store scenarios use Policy 6. Private domain single-store scenarios use Policy 7. Non-Taobao after-sales use Policy 9. The same sales delivery will not be processed by multiple channel policies simultaneously, but scheduling must avoid duplicate fetching.

Query policies (Policies 1–4) are all configured as no-op writes, used only for caching data into the hub, so they can be scheduled independently. Business policies (Policies 5–9) read mapping tables and lookup data from the hub during execution, so they must wait for the first full synchronization of master data policies before starting.

Best Practices

For scheduling, it is recommended to separate master data and business documents by time windows. Material, customer, and delivery queries run at high frequency during business hours 8:00–21:00 (every 10, 30, and 5 minutes respectively). Warehouse queries have a low change rate and are scheduled for daily full sync at 23:00. Sales order and return notice writing also runs every 30 minutes during 8:00–21:00, matching the upstream order generation cadence. All policies are incremental by default, filtering by modified, FModifyDate, FApproveDate, and similar timestamps. Full sync is used only during initial deployment or data repair.

For parallelism and dependencies, the four master data policies can run in parallel; Policies 5, 6, and 7 (sales order writing) can run in parallel; Policies 8 and 9 (return writing) can run in parallel. Serial dependencies exist only in two cases: master data must complete before business documents, and Policies 8 and 9 must wait for Policy 4 to complete the current cycle's delivery caching.

For exception handling, network timeouts and 5xx errors use exponential backoff, up to 3 retries at 1/2/4 minute intervals. Rate-limit 429 responses use linear backoff, up to 5 retries at 2-minute intervals. Unmapped codes and business validation failures are non-retryable errors, logged with reasons for manual intervention. Monitoring should focus on per-policy failure rate (alert above 10%), dead-letter queue accumulation (alert above 100 messages), sync latency (alert above 2 hours), and consecutive failure count (notify after ≥5 consecutive failures for the same policy).

For security, the solution does not contain any real enterprise information, API keys, or connection parameters. Codes and organization identifiers use placeholders or business-meaning descriptions. During implementation, actual connection credentials must be configured in the integration platform following the principle of least privilege.