Sync Warehouse Master Data from ERP-2 to Kingdee Cosmic: A Single-Strategy Tutorial
What This Strategy Solves
In retail or distribution supply chains, the e-commerce ERP runs warehouse operations while the financial ERP owns the accounting books. If warehouse master data is maintained independently in both systems, within three months you will see "a warehouse in the books but none in reality" or the reverse. This tutorial focuses on one strategy only: pushing newly added warehouses from the e-commerce ERP to the financial ERP in a single direction. It looks simple, but fields such as codes, enable status, organization, and address can easily go out of alignment if handled carelessly.
Data Flow and Field Mapping
The flow is unidirectional: E-commerce ERP (source) → Qeasy data integration platform (middleware for cleansing and mapping) → Financial ERP (target). Take a common three-party warehousing scenario: the source ERP maintains warehouse code, name, type, contact, and address; the target financial ERP additionally requires organization code, enable status, and accounting dimensions.
Key field mapping:
| Business meaning | Source field | Middleware handling | Target field | Notes |
|---|---|---|---|---|
| Warehouse code | warehouse_code | Trim, unify case | FNumber | Unique identifier |
| Warehouse name | warehouse_name | Remove special chars | FName | Truncate length |
| Warehouse type | type | Value mapping: finished/raw/virtual | FType | Dictionary table |
| Organization | org_code | Centralized code mapping | FOrgId | Required for multi-org |
| Enable status | status | 0/1 to Yes/No | FUsed | Enabled by default |
| Contact/phone | contact/tel | Concatenate | FContact | Length limit |
| Address | address | Split province/city | FAddress | Structured |
How to Configure on Qeasy
Step 1: Create a new integration project on the Qeasy data integration platform, named "E-commerce ERP Warehouse → Financial ERP Warehouse Add". Choose the e-commerce ERP connector type as source, fill in the endpoint and credentials (we strongly recommend using the platform's credential vault instead of hard-coding). Choose the financial ERP connector as target and run a connectivity test.
Step 2: Build an integration flow that pulls the source warehouse list API. Qeasy's list APIs typically support pagination and timestamp-based incremental. Here we use timestamp incremental — first pull full data, then only changes.
Step 3: Create a mapping table to map source English/pinyin fields to target financial ERP fields. A common practice among Qeasy customers is to centralize organization code mapping in a single "org mapping table" so that changes only need to be made in one place.
Step 4: Write a write action for the target. The financial ERP's warehouse save API is usually Save or Submit — first confirm whether the target system's status field means "effective on save" or a two-step "submit + approve".
Step 5: Add exception handling: retry 3 times on failure, do not block the entire batch on single failure, write error data to an exception table for troubleshooting.
Implementation Steps
We recommend a three-phase rollout:
Phase 1: Full initialization. Pick a cutover time on the source side and push all existing warehouses to the target. A safe approach: first run a "read-only shadow mode" on the target to compare field differences and duplicates, then enable writes after confirmation.
Phase 2: Incremental start point. After the first full load, record the source's last-modified time as the incremental start point. A common pattern among Qeasy customers is "incremental plus full dual-track": run incremental at dawn every day, then a full validation once a week to catch missed records.
Phase 3: Steady-state scheduling. Frequency depends on volume: high-volume enterprises can run every 5 minutes, low-volume can run hourly. Prefer scheduled triggers; if the source supports webhook notifications, you can also use event-driven mode, but design it to be idempotent to avoid duplicate pushes.
For rollout order, do the "header" fields first (code, name, organization, type), then the "body/extension" fields (contact, address, remarks). Phased rollout greatly reduces troubleshooting difficulty.
Lessons Learned
1. Decentralized organization code mapping. Multiple strategies each hard-coding their own mapping makes it impossible to update three months later when organizations change. The safe approach is to use Qeasy's centralized code mapping management.
2. Lost warehouse type value mapping. The source's "third-party warehouse" has no matching value in the target dictionary and defaults to "regular warehouse", causing subsequent inbound/outbound document type confusion. Always build a complete dictionary mapping table in the middleware.
3. Enable status not synced. The source disables a warehouse, but the target keeps the default "enabled", so documents still flow to the disabled warehouse. Status fields must be explicitly mapped, not rely on defaults.
4. Incremental start point misalignment causes duplicates. The time window between the first full load and the first incremental is not properly handled, producing duplicates. A typical mistake is using "today" as the incremental start point; the correct approach is to record the server time at the moment the full load completes.
5. Concatenated contact info exceeds length. Contact + phone combined into one field exceeds the target length limit and fails to save. Recommend length validation in the middleware before writing.
Applicable and Non-applicable Scenarios
Applicable: Single-organization or low-org-count retail/distribution enterprises where warehouse master data must remain consistent across systems and the source is the originating system. Not applicable: Multi-org complex accounting enterprises, scenarios requiring bidirectional sync, or enterprises where the warehouse business is led by the target (e.g., finance creates warehouses first, e-commerce connects later). Bidirectional sync introduces conflict resolution complexity and should be handled by a separate strategy.