Pushing Supplier Master Data from Qeasy to Kingdee Cosmic: A Single-Strategy Tutorial

What This Strategy Solves

In a retail supply chain integration, supplier master data is the starting point for purchasing, settlement, and reconciliation. If supplier additions, deactivations, and edits in the upstream system do not flow into Kingdee Cosmic in time, purchasing documents cannot be pushed because no valid supplier is found. We use the Qeasy Data Integration Platform (轻易云数据集成平台) to handle this segment and reliably deliver supplier master data into Cosmic. This strategy focuses on the "Qeasy → Cosmic - Supplier" stage and explains the middle-layer processing in detail.

Data Flow and Field Mapping

The overall flow is: Source (JuShuiTan) → Qeasy Middle Layer → Target (Kingdee Cosmic). The "Qeasy → Cosmic - Supplier" strategy is responsible for taking the normalized supplier data from the middle layer and writing it into Cosmic according to its field structure.

Key field mapping (simplified):

In real projects, the most common pitfall is code mapping. Cosmic-side groups, categories, and currencies are almost always IDs, not codes. A mapping table must be centrally managed in Qeasy rather than scattered across scripts. This is a common pattern among Qeasy customers: centralized code mapping.

How to Configure in Qeasy

We organize the configuration into four parts:

1. Data Source: The middle-layer supplier table, typically a view or physical table. It is recommended to include an updated_at field.
2. Target Source: The supplier save interface of Kingdee Cosmic V2. Note that Cosmic V2 is strict about required fields: FNumber, FName, and FSupplierGroupId are all mandatory.
3. Field Mapping: Done in the Qeasy mapping canvas. In addition to the table above, handle enum values: for example, the source status may be "Active/Inactive" and must be converted to a boolean or 0/1 for Cosmic.
4. Scripts and Cleansing: Trim whitespace, unify traditional/simplified Chinese, and normalize English case — all placed in Qeasy script nodes. Do not mix them into the save interface parameters.

We prefer to maintain code mappings in Qeasy's "Mapping Table" feature. When groupings are later adjusted, only one place needs to change — the strategy itself stays untouched.

Implementation Steps

We split supplier synchronization into a three-stage schedule:

Stage 1: Incremental Start Point During initial go-live, first set updated_at to a remote time (e.g., one year ago) and run a full reload. Once the full reload is complete, immediately write the "last sync timestamp" into Qeasy's variable table, and the incremental runs push data forward from that timestamp. A safe practice: the switch to incremental only happens after the full reload finishes, otherwise you end up with full reloads and incremental pushes running at the same time.

Stage 2: Full Reload Trigger Normally a daily full reload is not needed. We agree with the customer on two trigger modes:

• After upstream grouping adjustments, manually trigger one full reload.
• When accumulated failures on Qeasy exceed a threshold, automatically trigger a full reconciliation.

Stage 3: Schedule Frequency Supplier master data does not change frequently; an incremental run every 15 minutes is sufficient. Qeasy pulls data according to a schedule expression and, combined with the timestamp variable above, forms a dual-track of incremental and full reload.

After the schedule goes live, we attach a reconciliation node in Qeasy that compares the supplier code totals on both sides at midnight every day and alerts when the difference exceeds a threshold.

Lessons Learned from the Field

1. Code mapping scattered across scripts: In one engagement, the customer adjusted a group ID on the Cosmic side. Because the mapping was written into a strategy script and no one remembered to update it, an entire week's worth of suppliers went into the wrong group. After that, all mappings were moved to Qeasy's mapping table for centralized maintenance.
2. Required fields ignored: FSupplierGroupId is mandatory in Cosmic V2. If the source-side grouping is empty and the record is pushed directly, the entire batch fails. A safe practice is to add a pre-validation step on the Qeasy side: records with missing fields go straight to an exception queue and are never sent to the target system.
3. Incremental start point set incorrectly: A typical mistake is "running incremental on the very first day of go-live," which causes historical data to be missed. The incremental start point must be the timestamp at which the full reload completed, no shortcuts.
4. Header and line items pushed together: Supplier master data is header-level only with no line items, but in another project the customer treated supplier contacts as line items, which led to an extra loop in the Qeasy strategy and made debugging painful. After that, we made header/line staging a hard rule.
5. Deactivation status overwritten by mistake: After the source deactivated a supplier, the incremental run accidentally wrote the active status back into Cosmic. The cause was that the script upserted directly without checking the status field. A safe practice is to route deactivation through a separate status-update interface, instead of mixing it with the create/edit save path.

Suitable and Unsuitable Scenarios

Suitable: Single organization, suppliers in the tens of thousands or fewer, master data managed by a single source system, and no complex approval workflow — typical of small and mid-sized retail or distribution businesses. Not suitable: Multi-organization isolation, suppliers requiring tiered approval, multiple source systems writing in parallel, or scenarios requiring real-time (second-level) visibility of supplier changes — the latter needs event-driven architecture, not scheduled polling.