Practical Tutorial: Syncing Material Master Data from Kingdee Cloud Stellar Flagship to Xiaoman OKKI CRM

What This Strategy Solves

In one retail client we worked with, material master data had lived in Kingdee Cloud Stellar Flagship for years, while the sales team used Xiaoman OKKI CRM as their daily tool — picking products off the CRM to build quotes. Whenever material names, specifications, or availability changed in the ERP, the CRM still showed stale information. Sales reps walked into customer conversations with wrong data, and the numbers never lined up at the end of the month.

This strategy is designed to keep CRM product data consistent with ERP material master data: "change once in the ERP, the CRM follows." We use Qeasy (轻易云数据集成平台) as the integration backbone. Kingdee acts as the single source of truth, Xiaoman acts as the consumer, and the sync is strictly one-way.

Data Flow and Field Mapping

The flow has three layers: Kingdee Cloud Stellar Flagship → Qeasy integration middle layer → Xiaoman OKKI CRM. The middle layer does not persist data long-term; it focuses on field cleansing, code mapping, and type conversion.

Several transformations must be handled explicitly in the middle layer:

• Centralized code mapping: Kingdee's warehouse codes, category codes, and units rarely map one-to-one to Xiaoman's. Always build a mapping table in Qeasy; never hardcode conversions inside individual sync strategies.
• Status normalization: Kingdee's status is a combination of organization and a forbid flag, while Xiaoman only needs a boolean.
• Character cleansing: full-width symbols and special characters in names should be stripped in the middle layer to avoid insert failures on the CRM side.

How to Configure on Qeasy

In the Qeasy platform, this strategy is split into two actions: a Query action pulling data from Kingdee, and a Write action pushing data into Xiaoman.

Configuration points:

1. Data source connections: Use Qeasy's built-in Kingdee Cloud Stellar Flagship connector for the ERP side, and the OKKI CRM connector for the target.
2. Query strategy: Pull the Kingdee material list using FModifiedDate as the incremental cursor. Run a full sync the first time, then switch to incremental by modification time.
3. Field mapping: In Qeasy's mapping canvas, drag source fields to target fields. Use snake_case naming in the middle layer for easier maintenance.
4. Code mapping component: Route warehouse, category, and unit mappings through Qeasy's lookup table component. The mapping tables are maintained independently — field changes don't require touching the main flow.
5. Write strategy: When pushing to Xiaoman, match by code first; update if matched, insert if not. This is a typical "incremental + full dual-track" pattern that has proven stable across client deployments.
6. Exception handling: Enable "failed retry" and "write errors to exception queue" in the Qeasy task. Reviewing the exception queue after each run is a basic operational discipline.

Implementation Steps

We usually roll out the work in three phases:

Phase 1: Full initialization Manually trigger a full sync to push all existing Kingdee materials into Xiaoman. Run this during off-peak hours, validate first in a test environment, then verify record counts and key fields against both sides.

Phase 2: Calibrate the incremental starting point After the full sync completes, record the maximum modification time from Kingdee as the incremental start. In Qeasy's scheduling config, store this timestamp in a "last sync time" variable, and use it as the cursor for subsequent runs.

Phase 3: Turn on scheduled runs Material master data doesn't need real-time sync — every 15 minutes or every hour is usually enough. Configure a cron expression in Qeasy's scheduler: run during business hours, pause off-hours to avoid log noise.

During the first week after go-live, manually spot-check counts and a few sampled fields on both sides daily. Once stable, hand it over to automated operation.

Lessons from the Trenches

• Pitfall 1: Code mapping not centralized. One client had warehouse mappings hardcoded into every sync script. When business needs changed, they had to modify 10 strategy scripts. They later migrated all mappings to Qeasy's lookup table component — change once, apply everywhere.
• Pitfall 2: Active status ignoring organization dimension. Kingdee's forbid status is isolated by organization. A retail client with multiple regional organizations could have a material forbidden in org A but active in org B — you cannot judge from a single flag. The safe approach is to evaluate per target organization.
• Pitfall 3: Full and incremental mixed causing duplicates. When the full run completed but the incremental cursor wasn't refreshed, the same batch got re-pushed by the incremental job. Always force-refresh the incremental cursor inside the full-sync completion event.
• Pitfall 4: Special characters in units and specifications. Kingdee material names occasionally include full-width brackets or special symbols; Xiaoman's API validation is stricter and rejects them. The middle layer must do character cleansing.
• Pitfall 5: Rate limiting on Xiaoman. Xiaoman's API has call-frequency limits; bulk writes often trigger 429 responses. The Qeasy write side needs batch splitting and exponential backoff retries.

Suitable and Unsuitable Scenarios

Suitable: Enterprises where the ERP is the master data source and the CRM is the consumer; material master changes infrequently (daily or hourly); strict data consistency is required, no long-term drift between the two sides.

Not suitable: Scenarios where the CRM needs to do business processing and write back to the ERP; scenarios requiring sub-second real-time response; scenarios with massive structural differences that require dual master data management.