KIS Customer Master Data Sync to Jushuitan: Qeasy Configuration & Pitfall Guide

What This Strategy Solves

In retail and e-commerce integration scenarios, customer master data is often split between the ERP (here, KIS Private Cloud) and the e-commerce middleware (Jushuitan). In one real project, we ran into this exact problem: when customers updated their address, contact person, or phone number in the ERP, the e-commerce side was still using the old data, causing misdeliveries and surging return rates. Syncing KIS customer master data one-way into Jushuitan looks trivial, but it determines the data quality of every downstream order and shipment. This strategy is designed for the classic "single source of truth, downstream distribution" pattern for customer master data.

Data Flow and Field Mapping

The overall flow is one-way: KIS Private Cloud (source) → Qeasy middleware layer (clean, map, enrich) → Jushuitan (target).

Key field mapping example:

Note: The "no-op" in the source material does not mean the integration runs empty. When the customer record already exists at the target, it matches by code and skips writing — it only performs reconciliation and writes an audit log. This is a common "idempotent guard" pattern used on the Qeasy platform.

Configuring It on Qeasy

When we build this pipeline on the Qeasy Data Integration Platform, we usually follow these steps:

1. Source connector: Pick the KIS Private Cloud adapter and configure a database view or API pull entry. We recommend reading only the customer master data view to avoid pulling in unrelated fields.
2. Target connector: Pick the Jushuitan open-platform adapter and grant access to the customer/product related APIs.
3. Field mapping: Use Qeasy's visual mapper to build source-to-target field mappings. Centralized mapping management is a pattern frequently used by Qeasy customers — pull customer code and price-level mappings into a dedicated "mapping table" strategy, and have the main pipeline reference it rather than embedding mapping logic inline. This avoids ripple changes across multiple pipelines.
4. No-op branch: In the Qeasy "write to target" node, configure the idempotent policy "skip if primary key exists." This corresponds to the "no-op" semantics — no error, no duplicate write, only logging.
5. Exception handling: Enable retry-on-failure and alerting. Failed tasks go into a "manual review" queue, so dirty data never lands in the target system.

Implementation Steps

We usually roll this strategy out in three phases:

Phase 1: Full Initialization (one-shot trigger)

• In Qeasy, use "manual trigger + full mode" to push all customer records from the ERP at once, completing the first pass at the target.
• Immediately run a reconciliation: compare customer counts and spot-check key fields on both sides, and feed any differences back to the business owner for confirmation.

Phase 2: Incremental Anchor (first run watermark)

• Set the incremental start point (last_modified_time) to the timestamp when Phase 1's full run completed.
• This is the safe approach: never start incremental from "now," or you will lose every change made during the full-run window.

Phase 3: Steady-State Scheduling (incremental + full dual track)

• Incremental schedule: every 15–30 minutes, capturing new, modified, and deactivated customers from the ERP.
• Full fallback: weekly, or nightly during off-peak hours, to catch anything the incremental missed and heal historical dirty data.
• The "incremental + full dual track" pattern is well proven among Qeasy customers for master data like customers and materials.

Pitfall Retrospective

1. Address fields dumped as one blob. A classic mistake is pushing FAddress as-is into Jushuitan's address field. The e-commerce frontend cannot parse it structurally, so shipping cost calculation and electronic waybills break. The safe approach is to split into province/city/district first, then reassemble, or use Qeasy's split-merge operator.
2. Inconsistent phone field types. In KIS, FPhone may be nvarchar; Jushuitan expects a mix of strings and digits. Pushing it through directly can produce scientific notation or strip leading zeros. We recommend an explicit type normalization in the middleware layer.
3. Scattered code mappings. In one real project, we found customer code and price-level ID mapping logic duplicated across three different strategies. Updating one mapping meant editing three places. We later extracted it into a Qeasy "mapping table," cutting maintenance effort in half.
4. Deactivated customers not propagating status. When KIS deactivates a customer, it usually only flags a custom field. If is_active=false is not pushed to Jushuitan, the deactivated customer keeps placing orders, and the issue is only caught at finance reconciliation time. This is a common pitfall — make the status field mandatory.
5. No reconciliation after full run. Many teams finish a full initialization and switch straight to incremental mode, only to discover months later that data has drifted and the starting point is unclear. The safe pattern is: full run always reconciles, incremental always logs, reconciliation always archives.

When This Applies and When It Does Not

Applies: Single ERP as the source of truth for customer master data; downstream e-commerce, CRM, and WMS needing near-real-time sync; retail and distribution scenarios where customer record changes are infrequent but accuracy is critical.

Does not apply: Scenarios requiring bi-directional customer master maintenance, complex governance like merge/split/claim, or customer bases in the millions with sub-second latency requirements.