Cross-border Shop to Kingdee Customer Master Data Sync: A Single-Strategy Hands-On Tutorial

What This Strategy Solves

In cross-border e-commerce, the operating entity is the "shop," not the traditional notion of a customer. A retail enterprise might run dozens of shops across Amazon, Shopee, and Lazada simultaneously, and in Kingdee Cloud Stellar's supply chain, orders, shipments, and reconciliation all need to hang off a customer archive. The problem: shops live in Wangdiantong Cross-border Edition, but there is no matching customer in Stellar, so document flow breaks from the very first step.

This strategy uses the Qeasy data integration platform to pull shop records from Wangdiantong Cross-border Edition on an incremental basis (by creation time) and land them as Kingdee BD_Customer archives. It is not about "can it be sent over," but about how to unify master data without missing, duplicating, or polluting records.

Data Flow and Field Mapping

Data Flow: Wangdiantong Cross-border Edition (Shop) → Qeasy middle layer (idCheck dedup + mapping) → Kingdee Cloud Stellar (BD_Customer)

Key field mapping table:

Target otherRequest fixed parameters: FormId=BD_Customer, Operation=BatchSave, IsAutoSubmitAndAudit=true (save then audit), IsVerifyBaseDataField=true.

The source also exposes shopId, platformId, platformName, kjType, and remark, which are unmapped today. They can later be routed through COLLECTION mappings when splitting by platform into multiple orgs or attaching customer categories.

How to Configure in Qeasy

When implementing this strategy on site, the configuration on Qeasy is split into three blocks.

Source (Wangdiantong Cross-border Edition): type WebAPI, effect=QUERY, method POST, endpoint /api/openservices/shop/v1/getShopList. Set number to {{shopName}}, id to {{shopNo}}, and idCheck must be true—this is the dedup key. In the request body: start_time={{LAST_SYNC_TIME|datetime}}, end_time={{CURRENT_TIME|datetime}}, status=1 (filter by creation time), page_size=100.

Target (Kingdee Cloud Stellar): type EXECUTE, effect=EXECUTE, method POST, endpoint batchSave. Set both id and number to 0, and idCheck to true as well. The request body has the five fields from the table above, plus the four fixed otherRequest parameters.

Scheduling and chaining: source crontab */20 * * * *, target */25 * * * *, offset by five minutes so the target has a window to flush accumulated batches. If the customer's master data volume is higher, both can be raised to */10 and */15 in parallel.

Implementation Steps

We usually run this strategy in three phases.

Phase 1: Initialize the incremental starting point. On the very first run, LAST_SYNC_TIME is empty, so you need to manually set a starting point (for example, "7 days before now") to backfill historical shops. Running with an empty start time causes a full reload, which the source cannot handle.

Phase 2: Full trigger and reconciliation. Once the start point is set, immediately run a full pull and sample-check in BD_Customer: code, name, and org correctness. Focus on two numbers: total pulled vs. total landed, and whether source nulls are being written incorrectly.

Phase 3: Steady-state scheduling. After reconciliation passes, enable the dual */20 and */25 schedules. A common pattern among Qeasy customers is dual-track incremental plus full—incremental runs daily, and every Sunday at 02:00 a full pull acts as a safety net against LAST_SYNC_TIME drift or missed records.

Pitfall Postmortem

Pitfall 1: idCheck not enabled, or enabled on the wrong side. The source idCheck must be true; otherwise, already-synced shops will be re-written and FNumber collisions in Stellar will throw errors immediately. The target idCheck should also be true so the platform dedupes by id (shopNo).

Pitfall 2: Wrong status value. Source status=0 means filter by update time; status=1 means filter by creation time. The business wants "new shop → new customer." If mis-configured to 0, edits to old shops keep retriggering and pollute the data.

Pitfall 3: Hard-coded org constants bite you in multi-org scenarios. Today, FUseOrgId/FCreateOrgId are fixed at 100. A manufacturing-enterprise client later needed shops split by platform (Amazon shops into org A, Shopee shops into org B), and we had to retro-fit platformId into a COLLECTION mapping. The lesson: confirm the org dimension with the business before going live.

Pitfall 4: IsAutoSubmitAndAudit=true collides with downstream approval. If customer archives later need credit-limit approval, auto-audit skips the flow. In that case, turn auto-audit off and let downstream documents trigger it.

Pitfall 5: Hard-coded page_size=100 hits rate limits. Large cross-border sellers may create thousands of shops at once. Leaving page_size=100 unchanged risks the source paginating and cutting off results. Qeasy auto-paginates, but if new shops within the end_time window exceed the threshold, records can still be missed.

Suitable and Unsuitable Scenarios

Suitable: cross-border e-commerce with multiple shops, shops-as-customer entity, and the need to unify Wangdiantong Cross-border Edition master data into Kingdee Cloud Stellar to support downstream order, reconciliation, and inventory master data flow. Unsuitable: 1:N relationships between shops and customers, complex approval flows, source systems that do not support time-range incrementals, and complex scenarios requiring cross-strategy lookups for material or org mapping.