CRM and Kingdee Cloud Star Bidirectional Data Sync

Problem to solve

When sales teams maintain customers and orders in EC while operations manage product categories and materials in Kingdee Cloud Star, the two systems can drift apart. Customer master data may mismatch, closed orders may be missed, and categories can be duplicated. Manual field transfer is easy to get wrong on linkage keys such as crmId and productId, and it can mix individual customers with company customers.

How the skill works

The skill splits synchronization into two directions:

• EC → Kingdee: Hourly, it pulls EC customers and closed orders with status=3, then writes them into Kingdee customer profiles and sales orders. Customers are deduplicated by using EC crmId as Kingdee number; existing records are updated and missing records are created. Orders map code with an EC- prefix and carry over amount, material, date, and remarks.
• Kingdee → EC: Daily at 01:00, it pulls Kingdee product categories and creates EC products. Defaults include productUnit=each, money=0.00, and onOff=0, while local mapping and product-name matching prevent duplicates.

Both directions store timestamps for incremental pulls; the first run can be forced to full sync with --full when needed.

Boundaries and notes

• EC getSales queries cannot span a creatTime range longer than 31 days, so large batch syncs should be split.
• Kingdee app-token is valid for 24 hours and is cached and refreshed automatically.
• productId is mapped directly to Kingdee materialid_id; the matching material must already exist in Kingdee.
• Field mappings live in map_ec_customer_to_jdy() and map_ec_order_to_jdy(), so new customer or order fields need business-specific adjustments.