Supplier Master Sync from Jushuitan to Kingdee Cosmic: A Single-Strategy Deep Dive

What This Strategy Solves

Supplier master data is one of the most underestimated foundational datasets in supply chain integration. In one retail project where we integrated Jushuitan with Kingdee Cosmic, the source-side supplier records were maintained by procurement and operations, while the target-side supplier files had to support financial accounting and accounts payable. When both sides are managed independently, within three to six months you typically see code splits, name drift, and inconsistent tax information—payment teams then spend weeks chasing missing paperwork. We used the Qeasy Data Integration Platform to host this strategy, with the goal of establishing a single trusted source so that the Kingdee side always opens accounts based on the latest supplier master from Jushuitan.

Data Flow and Field Mapping

The overall flow is Jushuitan (supplier) → Qeasy middle layer → Kingdee Cosmic (supplier). The middle layer handles four jobs: extraction, cleansing, mapping, and transformation—keeping any dirty data away from the target system.

Key field mapping table:

Code mapping must be centrally managed and never scattered across individual field conversions. We recommend maintaining a supplier category mapping table in Qeasy's Data Mapping Center, owned by the data governance team.

How to Configure in Qeasy

Configuration falls into four blocks—all patterns we repeatedly use during on-site implementation.

Step 1: Source connector. Use Qeasy's built-in Jushuitan connector and configure authorization according to the platform's interface specification. The supplier endpoint typically supports paginated retrieval and incremental queries by update time; the connector parameters for both must be explicitly set.

Step 2: Target connector. The Kingdee Cosmic connector needs to follow its standard interface protocol. We recommend organization-isolated credentials to avoid one integration account being shared across the entire group.

Step 3: Data mapping. In Qeasy's Data Mapping canvas, drag source fields onto target fields and use expressions for complex logic. Typical expressions include: lookup-based category ID replacement, name concatenation with organization suffix, and phone number whitespace stripping.

Step 4: Write policy. We recommend an upsert semantics: match by code, update if exists, create otherwise. Qeasy's write node supports batch submission to Kingdee Cosmic, but keeping each batch under 200 records is safer—larger batches tend to trigger rate limits on the target side.

Implementation Steps

Phased scheduling is the standard for this kind of foundational data sync. We use a three-stage approach: incremental starting point, full trigger, and scheduling frequency.

1. Incremental starting point. For the first launch, set an incremental start timestamp in Qeasy, ideally at 00:00:00 on the project kick-off day. The first run only pulls changes made after launch, leaving the full dataset to the full-trigger step.

2. Full trigger. The first sync should use full-trigger mode and run a complete supplier extraction and write manually. The purpose is not "sync" but "reconciliation"—after the run, spot-check three critical fields (code, name, tax ID) and only enable scheduled jobs after verification.

3. Scheduling frequency. Supplier master changes far less frequently than items or orders; we usually recommend hourly incremental runs. Qeasy's scheduler supports cron expressions, and an hourly cadence combined with Jushuitan's incremental cursor keeps end-to-end latency within one hour.

During implementation, run a "breakpoint recovery drill": intentionally stop the integration job for 30 minutes and then resume, confirming that Qeasy's cursor memory and replay mechanism can correctly continue without duplicate writes or missing records.

Lessons Learned

Pitfall 1: Unstandardized code prefixes. In one project, the source code was GYS001 and the target landed as GYS001 too. Six months later, Kingdee opened multi-organization and code collisions appeared during cross-org transfers. The safe approach is to add an organization prefix in the middle layer, handled uniformly by Qeasy expressions.

Pitfall 2: Category mapping scattered across transformation scripts. In the first version, to save time we hard-coded category mappings inside transformation scripts. Whenever business adjusted a category, we had to redeploy. Later, we migrated everything to Qeasy's Mapping Center for centralized maintenance, which business owners can update on their own.

Pitfall 3: Incremental cursor tripped by time zones. Jushuitan's incremental field uses local time while Kingdee uses UTC. In a cross-time-zone engagement, data had clearly been updated but refused to sync. The reliable approach is to convert the source time to the target's time zone in Qeasy before comparison.

Pitfall 4: Disabled suppliers resurrected. When the source disabled a supplier, incremental sync treated it as an ordinary update and overwrote the target's enable flag. The correct handling is to explicitly check the status field in the middle layer—mapping disabled to the target's disable flag rather than simple overwrite.

Pitfall 5: Batch submission hit rate limits. Submitting over a thousand suppliers at once caused Kingdee Cosmic to return rate-limit errors. Qeasy's write node does have built-in retry with backoff, but batch size must be manually controlled—we recommend 200 records per batch.

When This Applies and When It Does Not

Applies: Single or few-organization supplier master synchronization, low change frequency, scenarios where reconciliation and accounting heavily depend on master data consistency.

Does not apply: Multi-language, multi-tax-regime, or cross-border supplier scenarios; supplier onboarding flows that require complex approval workflows; and architectures where neither Jushuitan nor Kingdee Cosmic is the trusted master source.