Practical Guide: Syncing Kingdee Cloud Skylink Sales Outbound Orders to Wangdiantong Raw Orders via Qeasy

What This Strategy Solves (Scenario & Value)

In one multi-channel retail project, we ran into a classic pain point: store and e-commerce orders are fulfilled in Kingdee Cloud Skylink (sales outbound documents), but the Wangdiantong platform still needs a "raw order" record to drive shipping, after-sales, and settlement. Manual re-entry cannot keep up with the volume. So we used the Qeasy data integration platform to build a single strategy: every few minutes, push audited Kingdee sales outbound documents to Wangdiantong·QiMmen as raw orders. The pipeline only does one thing—move the document—and we keep return writes and status updates in separate strategies, so the boundaries stay clean.

Data Flow & Field Mapping (Source → Middle Layer → Target)

The source is Kingdee's SAL_OUTSTOCK (sales outbound document). The target is Wangdiantong's wdt.trade.push (raw order push). In Qeasy, data is pulled from the source, transformed through field mapping and scripts, then written to the target API.

Key field mapping (header):

Key field mapping (line items):

Source filter (configured directly in Qeasy's source query):

FCreateDate>='{{LAST_SYNC_TIME|datetime}}'
AND FDocumentStatus='A'
AND F_VTRK_Assistant <> ''
AND F_VTRK_Text11 <> ''
AND F_VTRK_Text12 <> ''
AND F_VTRK_Text13 <> ''
AND F_VTRK_Text10 =''

The common pitfalls are already blocked here: only audited docs, with a shop, with complete province/city/district, and not previously pushed.

How to Configure It in Qeasy

On the Qeasy strategy canvas, this strategy is split into three segments: source query → script processing → target write.

1. Source config: Business object SAL_OUTSTOCK, API executeBillQuery, pagination via {{PAGINATION_PAGE_SIZE}} and {{PAGINATION_START_ROW}}, primary key FBillNo, line ID FEntity_FENTRYID.
2. AfterSourceInvoke script: A PHP script handles the indoor/outdoor unit split for air-conditioner products. If F_VTRK_Text9 (outer-unit material code) exists, it becomes the main material; if F_VTRK_Text6 (Wangdiantong name) or F_VTRK_Text9 is non-empty, additional line items are appended, all using FRealQty for quantity. This is the "soul" of the strategy—validate the split in a test environment with a few real air-conditioner outbound documents before going live.
3. Target write: API wdt.trade.push, request body built from the header mapping above. Constants are written directly in Qeasy field config. shop_no is passed via otherRequest. switch=0 (non-strict mode) so a single bad field doesn't fail the entire document.

We also applied several patterns we often see in Qeasy customer projects: centralized code mapping (shop and material mappings live in one table, so adding a new shop does not require touching the strategy); header/line staged processing (header fields mapped first, line items processed by script afterward, so failures stay row-scoped); dual-track incremental + full sync (5-minute incremental in normal operation, with manual full-range replays by FCreateDate when something goes wrong).

Implementation Steps

1. First go-live: full baseline. Set LAST_SYNC_TIME to a past timestamp (e.g., midnight of the project kickoff day), trigger a manual run to push all existing audited sales outbound documents. Immediately write back F_VTRK_Text10 = 'synced' to prevent re-pushing in the next cycle.
2. Daily schedule: 5-minute incremental. Configure the schedule as */5 6-23 * * * (every 5 minutes between 06:00 and 23:00). The FCreateDate>=LAST_SYNC_TIME filter automatically picks up only deltas. After each successful run, Qeasy advances LAST_SYNC_TIME to the latest timestamp seen.
3. Retry & alerting. Qeasy retries by default, but we recommend surfacing business errors from Wangdiantong (e.g., "shop not found", "spec not found") to a manual queue—fix the mapping table, then replay. Avoid infinite retries on business errors.
4. Return writes live in another strategy. This strategy only pushes outbound → raw order in one direction. Logistics numbers and sign-off status coming back from Wangdiantong to Kingdee should be handled by a separate strategy to keep concerns separated.

Pitfalls We Hit in the Field

• tid uniqueness. Wangdiantong requires tid to be unique within a sid. We initially used only FBillNo, and two documents with the same contract number in the same shop got rejected. The reliable pattern is the three-part contract-line_FID concatenation shown in the spec—non-duplicate and traceable back to the source.
• Empty province/city/district. Without a strong address-completeness check upstream, Wangdiantong simply errors out. Adding F_VTRK_Text11/12/13 to the filter means incomplete-address docs are skipped until business fills them in.
• Indoor/outdoor units becoming two orders. Before adding the AfterSourceInvoke script, indoor and outdoor units generated two separate raw orders, and reconciliation broke. With the script, a single sales outbound line is split into main-material + outer-unit + Wangdiantong-name lines, all under the same tid.
• Hard-coding monetary fields to 0 is intentional. A common reflex is to map unit price and discount across, but Wangdiantong treats them as "specified price" and rejects. Per the spec, leave monetary fields at 0 and let the platform resolve them from the product master via spec_no.
• Forgetting to write back F_VTRK_Text10. If the "synced" flag is not written back, the next incremental run pushes the same documents again. Always add a writeback step (either inline or as a downstream strategy); otherwise the two sides will drift within a quarter.

When This Strategy Fits (and When It Doesn't)

Fits: Mid-volume multi-channel retail/manufacturing where 5-minute latency is acceptable, source is Kingdee Cloud Skylink sales outbound, target is Wangdiantong raw order, and shop/material/address mappings are relatively stable. Doesn't fit: Sub-second real-time needs (use message queues or event-driven triggers instead); multiple target platforms (split into multiple strategies instead of stuffing fields); scenarios requiring heavy business validation before push (this strategy is a pure carrier—validation belongs upstream).