Purchase Order Sync Strategy in Practice: From Xiaoman OKKI CRM to Kingdee Cloud Xingchen

What This Strategy Solves

For many import/export companies, front-end sales and purchasing collaboration runs in Xiaoman OKKI CRM, while back-end finance and supply-chain accounting live in Kingdee Cloud Xingchen. Once a purchasing rep places a purchase order in the CRM, the team expects the order to immediately show up in Xingchen for bookkeeping, goods receipt, and supplier reconciliation. The two systems use different coding rules, field semantics, and state machines, so manual double entry inevitably leads to mismatched numbers within three months. We use the Qeasy (Qingyi Cloud) data integration platform to take ownership of this single "purchase order sync" strategy: CRM is the master data source, ERP is the destination, and the goal is one order, two systems, fully consistent.

Data Flow and Field Mapping

The data flow is unidirectional: Xiaoman OKKI CRM (source) → Qeasy middle layer → Kingdee Cloud Xingchen (target). The middle layer handles code conversion, field completion, and status alignment; we do not touch the source system directly.

Key field mapping table (typical import/export scenario):

Two details are easy to get wrong. First, the "material code" must wait until the master data sync has finished, otherwise the ERP will reject the entire order because the material does not yet exist. Second, the "document status" must be explicitly translated in the middle layer; never pass it through as-is.

How to Configure in Qeasy

In the Qeasy console, this strategy has four key configuration points.

First, data source connections. The source uses the OKKI OpenAPI; the target uses Xingchen's open platform. All credentials are stored in Qeasy's centralized credential vault — never hard-coded inside strategy scripts.

Second, field mapping and code mapping. We strongly recommend centralizing vendor, currency, employee, and material mappings into a single "code mapping table" rather than scattering them across strategies. The most common pattern we see on customer sites is "centralized code mapping" — when a sales order sync strategy is added later, it reuses the same mapping table.

Third, transformation scripts. Header fields do lightweight transformations (date format, status mapping, currency validation); line items are handled separately. If the customer needs both header and line items, the safe approach is phased delivery: ship the header first, stabilize it, then layer on the line items. This avoids writing dirty data into the ERP in one shot.

Fourth, write policy. Xingchen's default is "save-and-approve," but in production we usually change it to "save" first, landing a draft that is approved by a human or by a downstream strategy. This prevents dirty data from entering the financial chain.

Implementation Steps

We recommend going live in three phases.

Phase 1: Full initialization. Pick a historical cutoff in the CRM, then push every purchase order before that cutoff into Xingchen in one batch. This is a one-time full sync task; mark "full sync complete" when done.

Phase 2: Incremental cutoff switch. Use the full-sync cutoff as the incremental starting point. From then on, push only new or modified orders. Use the CRM's "last modified time" as the cursor — do not use "order date," which will repeatedly pull historical orders.

Phase 3: Scheduling frequency. Import/export business does not usually require extreme real-time latency, so a 15-minute interval is sufficient. If the customer is latency-sensitive, you can compress to 5 minutes, but first verify Xingchen's API QPS limits. Qeasy scheduling supports both cron and fixed-interval modes; "fixed interval 15 minutes" is the more intuitive choice.

In addition, enable Qeasy's "retry on failure + alert notification": retry 3 times on first failure, then route persistently failing orders to an "exception queue" and notify ops via enterprise WeChat or email.

Pitfall Review

Pitfall 1: Materials not synced first. Before running purchase order sync, the "material sync" strategy must have been stable for at least one week. Otherwise, orders will be rejected wholesale at the ERP because the materials do not exist yet.

Pitfall 2: Currency and tax rate passed through as-is. Sales reps in the CRM sometimes pick a currency that is not enabled in the ERP, or use a tax rate with mismatched precision. Always validate in the middle layer; do not trust source data blindly.

Pitfall 3: Status machine misalignment. CRM's "approved" is not the same as ERP's "approved." CRM's "approved" usually maps to ERP's "pending receipt." This must be explicitly captured in the mapping table — do not take the lazy route and pass through.

Pitfall 4: Wrong incremental cursor. Using "order date" as the incremental cursor is a classic mistake. It causes historical orders to be pulled repeatedly, wasting API quota and potentially creating duplicate documents on the ERP side. The safe approach is to use the CRM's "last modified time."

Pitfall 5: Save-and-approve by default. In production, the default "save-and-approve" submits drafts as well, polluting later financial reconciliation. Land orders as "saved" first, then trigger approval only after validation.

When to Use and When Not to Use

Use when: CRM is the front-end business system and ERP is the back-end accounting system; order volume ranges from a few hundred to a few thousand per day; real-time requirement is at the minute level. Do not use when: bidirectional sync is required (ERP writing back into CRM); order structures differ so heavily on both sides that heavy custom development is needed; or business volume is so small that manual entry is more cost-effective.