KIS Private Cloud and JuShuiTan Supply Chain Integration Solution
Scenario and Value
In the context of scaled e-commerce operations, retail enterprises commonly face data fragmentation between ERP and e-commerce WMS systems. Kingdee KIS Private Cloud, as the financial and supply chain core system, manages master data such as materials, suppliers, and customers, along with purchase, sales, and inventory business documents. JuShuiTan, as a system integrating with multi-platform e-commerce orders and warehouse fulfillment, generates delivery orders, return orders, purchase inbound orders, and various inventory movement documents. When these two systems operate independently without systematic data connectivity, it leads to inconsistencies between accounts and physical inventory, delayed inventory data, and inability to timely record purchase returns and sales outbound transactions.
This solution targets the typical "ERP + e-commerce WMS" supply chain integration scenario, aiming to build a bidirectional data channel between KIS Private Cloud and JuShuiTan: master data flows from KIS to JuShuiTan, while business documents flow from JuShuiTan back to KIS. This achieves consistency in product, supplier, customer, and warehouse codes, as well as real-time synchronization of delivery, return, purchase, and inventory movement documents.
Integration Architecture and Data Flow
The overall architecture is centered on the integration platform, with both ends connecting to KIS Private Cloud (Kingdee ERP) and JuShuiTan (including JuShuiTan Qimen interface). The integration platform handles protocol adaptation, scheduling orchestration, code mapping, exception retry, and alert notification.
The data flow is divided into two directions:
- A→B (KIS Private Cloud → JuShuiTan): Master data direction. KIS material master data and supplier master data are pushed to JuShuiTan as product and supplier records.
- B→A (JuShuiTan → KIS Private Cloud): Business document direction. JuShuiTan's delivery orders, return orders, purchase inbound orders, other inbound/outbound orders, inventory profit/loss, transfer orders, and purchase return orders are written back to KIS, generating corresponding sales outbound orders, red-word sales outbound orders, purchase inbound orders, other inbound/outbound orders, and purchase return orders.
In terms of dependencies, master data must be synchronized before business documents. Before materials are pushed, any document synchronization containing material codes will fail due to missing code mapping. Before suppliers are pushed, purchase inbound and purchase return cannot be written either.
Interface List
This solution plans a total of 21 integration strategies, of which 15 are effective business synchronizations, and the rest are no-op, query, or alert auxiliary strategies.
| Source Platform | Target Platform | Data Object | Sync Direction |
|---|---|---|---|
| KIS Private Cloud | JuShuiTan | Material → Product | A→B |
| KIS Private Cloud | JuShuiTan | Supplier → Supplier | A→B |
| JuShuiTan | KIS Private Cloud | Delivery Order → Sales Outbound Order | B→A |
| JuShuiTan | KIS Private Cloud | Return Order → Red-word Sales Outbound Order | B→A |
| JuShuiTan | KIS Private Cloud | Purchase Inbound Order → Purchase Inbound Order | B→A |
| JuShuiTan | KIS Private Cloud | Other Inbound Order → Other Inbound Order | B→A |
| JuShuiTan | KIS Private Cloud | Other Outbound Order → Other Outbound Order | B→A |
| JuShuiTan | KIS Private Cloud | Inventory Profit → Other Inbound | B→A |
| JuShuiTan | KIS Private Cloud | Inventory Loss → Other Outbound | B→A |
| JuShuiTan | KIS Private Cloud | Transfer Out → Other Outbound | B→A |
| JuShuiTan | KIS Private Cloud | Transfer In → Other Inbound | B→A |
| JuShuiTan | KIS Private Cloud | Purchase Return Order → Purchase Return Order | B→A |
In addition, Qimen and non-Qimen interfaces have two sets of strategies for delivery orders and return orders. During implementation, one should be selected or both kept based on the actual authorization situation of the enterprise.
Implementation Points
Field Mapping: For material synchronization, KIS F_103 is used as JuShuiTan sku_id and i_id, with material name mapped directly. For suppliers, FNumber corresponds to supplier_code. For delivery orders, io_id is used as KIS external order number; the receiving address is concatenated from province, city, district, and detailed address, with logistics company and tracking number mapped directly. Return orders need to be written based on actual received quantity (items_r_qty), and the amount for red-word outbound orders is negative.
Code Mapping: Mapping tables need to be maintained for material codes, supplier codes, customer codes, and warehouse codes. Material and supplier mappings are automatically established through KIS→JuShuiTan strategies, with reverse synchronization querying the mapping table. Customer codes and warehouse codes typically require manual maintenance.
Interface Limitations: The Qimen interface has a single time window not exceeding 7 days, requiring paginated pulling by time windows. The JuShuiTan product upload is a batch interface, requiring data to be split into batches (e.g., 100 records per batch) before calling.
Status Filtering: Delivery orders are synchronized only when in shipped status, return orders only when the seller has received the return, and purchase inbound and other inbound/outbound orders only when in Confirmed status.
Key Verification Items: The non-Qimen return order interface (Strategy 10) is marked as "problematic" in the solution. Before implementation, field compatibility and availability need to be confirmed against the latest API documentation from JuShuiTan and KIS.
Best Practices
Layered Scheduling: Master data is recommended to be synchronized every 30 minutes. Sales outbound types (delivery orders, return orders) should be configured at 30 minutes to 1 hour according to business volume. Purchase inbound and inventory movement types are recommended at every 10 to 30 minutes. Enterprise WeChat alerts use event-triggered rather than polling. After the master data phase is completed, the business document phase can be initiated, and strategies within the phase should be executed at staggered intervals, controlling concurrency to avoid pressure on KIS.
Combining Incremental and Full Synchronization: Daily operations are primarily incremental, using LAST_SYNC_TIME or modified_begin/end to control windows. Full synchronization is used for initialization and data repair scenarios, requiring attention to pagination and rate limiting. A common practice is to perform full verification of master data periodically while only incrementally synchronizing business documents.
Exception Handling: Network timeouts use exponential backoff (2s, 4s, 8s). Interface rate limiting waits 60 seconds after detecting 429 before retrying. Business validation failures are not retried and directly enter manual processing. External order numbers are used for idempotent deduplication to avoid duplicate submissions.
Alert Mechanism: When single synchronization failure rate exceeds 10%, the same strategy fails consecutively 3 times, pending synchronization data volume exceeds 1000 records, or the source or target system returns HTTP 5xx, alerts should be triggered through Enterprise WeChat or email. Code mapping missing records are recommended to be aggregated daily to avoid excessive log length.
Data Security: Solution documents do not contain example values for sensitive information such as enterprise names, customer names, phone numbers, or addresses. Interface authentication information (tokens, appkeys, etc.) is configured on the integration platform side, and log and alert content needs to be desensitized.
Full Synchronization Window: Full synchronization is recommended to be executed during business off-peak hours (e.g., early morning) to reduce impact on online transactions.