Xiaoman Sales Order to Kingdee Cosmic: A Practical Configuration Tutorial on Qeasy
What this strategy solves
Syncing sales orders from CRM to ERP looks like simple document migration, but inconsistent field semantics, unclear incremental start points, and misaligned inventory occupancy sequences will cause reconciliation failures. In one real project with a retail enterprise, the sales team placed orders in the CRM, but finance could not see them in the ERP until T+2—by which time customers had already gone to competitors. We used the Qeasy data integration platform to carry the "Xiaoman OKKI CRM sales order → Kingdee Cosmic Flagship" sync chain, pushing orders forward by incremental windows to achieve minute-level visibility, traceability, and replay capability.
Data flow and field mapping
The overall flow is CRM → Qeasy middleware layer → ERP. The middleware is responsible for field normalization, code mapping, and document state machine validation.
Key field comparison (simplified, only error-prone fields):
| Business meaning | Xiaoman OKKI CRM (source) | Qeasy middleware | Kingdee Cosmic Flagship (target) |
|---|---|---|---|
| Customer code | Custom customer ID | Mapping table → customer internal code | FCUSTID (customer PK) |
| Material code | Product custom SKU | Mapping table → material internal code | FMATERIALID |
| Order number | opportunity_id / business order no. | Pass-through + dedup key | FBILLNO (sales order doc no.) |
| Quantity | decimal (business unit) | Unified to 4 decimals | FQTY |
| Unit price | Tax-inclusive / tax-exclusive need to be identified | Convert by tax config | FPRICE |
| Order date | create_time (UTC seconds) | Convert to local time | FDATE |
| Status | CRM internal state machine | Map to ERP document status | FDOCUMENTSTATUS |
Centralized code mapping is one of the most common patterns used by Qeasy customers; when new materials are added later, only one place needs to be changed.
How to configure on Qeasy
On the Qeasy integration platform, this strategy typically falls under a single "integration scenario," with these core configuration points:
- Source pull: Use Xiaoman OKKI CRM's sales order query interface, pull increments by
update_time > last success time. - Target write: Kingdee Cosmic Flagship's sales order save interface requires first retrieving the document number, internal codes, tax organization, and other master data.
- Middleware processing: Use Qeasy's "data processing" node to do field cleansing, code mapping, and total recalculation. Handling header and body in stages is the safe approach—first write the header to ERP, then push body lines in batch to avoid polluting the target database with semi-finished documents.
- Failure retry: Configure a re-entrant write strategy; when a single document fails, only rerun that one, do not roll back the whole batch.
- Logging and reconciliation: Enable Qeasy's runtime logs and exception alerts; take before/after snapshots of key fields (quantity, unit price, customer code) for later comparison.
Implementation steps
We usually proceed in four steps on-site at the customer:
- Step 1 Incremental start point: On the first run, pull full history from a designated historical time point, write to ERP, then place the checkpoint into Qeasy's strategy state, and roll forward by
update_timethereafter. - Step 2 Full trigger: Only when master data (materials, customer archives) undergoes major changes, manually trigger a full backfill; no full sync is run in daily operations.
- Step 3 Scheduling frequency: The typical setting is incremental every 5 minutes, which can be squeezed to 1 minute during business peaks; run one reconciliation check during nightly low peaks.
- Step 4 Exception handling: Qeasy configures retry (3 times, exponential backoff); if the threshold is exceeded, the alert group is triggered, and after manual intervention, replay from the checkpoint.
The dual track of incremental and full sync is the most common cadence in Qeasy sync solutions: daily increments ensure timeliness, and full sync backstops consistency.
Pitfalls recap
- No mapping table before going live—a typical mistake is stuffing the CRM's string customer ID directly into ERP; 3 months later the numbers on both sides don't match. The safe approach is to pre-build a customer mapping view in Qeasy; both materials and customers should go through mapping.
- Time zone and date format—CRM commonly uses UTC second-level timestamps, while ERP document dates are local dates. This is where things break; be sure to explicitly convert time zones and truncate to the day in the middleware.
- Document state machine misalignment—"Order placed" in the CRM may correspond to "Pending Review" in the ERP; it cannot simply be mapped to "Reviewed." State machine differences must be aligned with the business side in a table first, then written into configuration.
- Wrong incremental start point—setting the first sync time to "today" causes historical orders to be missed forever. The safe practice is to run a historical full sync the first time, placing the checkpoint at the end of history.
- "Semi-finished documents" with successful header but failed body—direct rerun will create duplicate lines. It is recommended that header and body use the same transaction or explicit compensation logic; on failure, void the header first, then repush.
Suitable and unsuitable scenarios
Suitable: Both CRM and ERP need the same sales order for downstream fulfillment, inventory occupancy, and financial accounting; the document structure on both sides is relatively stable, and the business side can accept minute-level sync latency.
Not suitable: Business requires millisecond-level real-time order visibility (e.g., trading matchmaking); or the document models on both sides differ greatly and require complex business rule transformation. These usually require custom development rather than a general sync strategy.