Sales Delivery Sync from Wangdiantong to Chanjet T+: A Single-Strategy Integration Tutorial

What This Strategy Solves (Scenario & Value)

In one retail project we worked on, the front end ran on Wangdiantong for e-commerce orders, while the back-end finance and inventory lived in Chanjet T+. Each side managed its own slice, which sounded clean — but sales delivery documents got stuck in the middle. Finance posting was delayed, on-book inventory no longer matched physical stock, and monthly reconciliation dragged on. We bridged the gap with Qeasy (Qingyiyun Data Integration Platform), pulling delivery documents every 10 minutes from the source side and pushing them into T+'s sales delivery API once a day in the early morning, so both sides reconcile by the next business day. The strategy below is a standard "source query + target execute" combo, and it serves as the foundation for the other five strategies in the same solution.

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

Data lands in the Qeasy middle layer first, then gets consumed by downstream strategies. This way, re-issuing, fixing, or re-pushing a document does not require going back to disturb the source system.

Source side (Wangdiantong query) goes through Qeasy's QueryStrategyData endpoint to pull sales delivery data. Key inputs:

• strategy_id: identifies the strategy to query
• status: data status; here it is 0 (waiting), and multiple statuses can be combined with ,
• created_at_begin / created_at_end: incremental window bound to {{LAST_SYNC_TIME}} and {{CURRENT_TIME}} for time-window rolling

Target side (Chanjet T+ execute) writes via /tplus/api/v2/saleDelivery/Create. Core field mapping:

Warehouse, customer, and SKU mappings are the three spots that break most often. Keep them centralized inside Qeasy rather than scattered across scripts.

How to Configure in Qeasy

1. Source strategy (Query): effect=QUERY, method POST, idCheck enabled, autoFillResponse=true so the platform auto-fills response fields and reduces manual mapping.
2. Target strategy (Execute): effect=EXECUTE, bind T+ WebAPI credentials, use an expression to assemble ExternalCode so writes stay idempotent.
3. Credentials & namespaces: Register T+'s platform_id and credentials once in Qeasy's "System Integration" section so every strategy reuses them — no per-strategy duplication.
4. Code mapping: For warehouse, customer, and SKU, use Qeasy's mapping table component with consistent field names so future strategies reuse them at zero cost.

Implementation Steps

We recommend rolling this out in three stages.

Stage 1 — Incremental starting point. Lock created_at_begin to a fixed backtrack point (e.g. 7 days before go-live), narrow status to 0,5, and get a single document flowing end-to-end. Confirm the document appears in T+ and that the external code is unique.

Stage 2 — Full backfill. Once Stage 1 is stable, widen the window to full and trigger a manual run to flush historical backlog. At the same time, fill in any mapping-table entries you missed.

Stage 3 — Scheduler cadence. Source crontab = */10 * * * * (every 10 minutes); target crontab = 23 5 * * * (5:23 AM daily). Source polls frequently to accumulate batches; target pushes in low-frequency batches. This reduces load on T+ and avoids contention with overnight business peaks. The "high-frequency pull, low-frequency push" dual-track is one of the most common patterns we see across Qeasy customers.

Pitfalls We Have Seen

1. Duplicate ExternalCode rejecting the whole batch. consign_time_new alone is not unique — append the shop number, and ideally a tail from the source document number. Otherwise T+'s uniqueness check rejects the entire batch.
2. Warehouse codes misaligned on both sides. The Wangdiantong side may say "East-1" while T+ says "01" or "HD01". If you don't centralize the mapping table in Qeasy, three months later when the numbers don't match, you cannot trace the origin.
3. Wrong status filter causing lost orders. Querying only 0 (waiting) misses in-review and completed records. The safe approach is to combine 0,5,3 and write the status back after a successful push.
4. Time-window variables not initialized. On the first run, {{LAST_SYNC_TIME}} is empty, so the source re-pulls everything. Set a default backtrack value in the strategy, or predefine it in Qeasy's "Initial Sync Time".
5. Pushing header and lines together makes errors hard to locate. A sales delivery has both header and line items. In one project we asked the customer to push the header first and only the lines afterwards once stable — this is the typical "header-then-lines in stages" approach and it dramatically speeds up troubleshooting.

When to Use vs. When Not to Use

Use it when: a mid-sized retailer uses Wangdiantong as the order front end and T+ for finance and inventory; daily order volume is in the low thousands; T+1 reconciliation is acceptable. Do not use it when: real-time sync is required (sub-minute latency), there are complex inter-company transactions, or the daily volume exceeds what T+ WebAPI can absorb. In those cases, fall back to a direct database link or a dedicated inventory staging table.