Authoritative Tutorial on Interface Field Manual for Wangdiantong and Kingdee Cloud Galaxy Supply Chain Integration

What Problem Does This Interface Solve

In the mid-office and back-office architecture of retail and e-commerce enterprises, Wangdiantong serves as the front-end WMS/ERP for business documents, while Kingdee Cloud Galaxy handles financial and supply chain mid-platform accounting. If sales outbound, purchase inbound, transfers, returns, and master data between the two systems are entered manually, it is highly prone to inconsistent inventory calibration, accounts receivable/payable errors, and cross-organization reconciliation difficulties. This tutorial focuses on the interface field practice of the "Wangdiantong ↔ Kingdee Cloud Galaxy" supply chain integration, allowing readers to master the core fields, mapping rules, and implementation experience of all 23 strategies in one go.

Interface Capability Overview

• Authentication: Wangdiantong uses application-level API key signature; Kingdee Cloud Galaxy uses WebAPI login token + organization code. Both are encapsulated as visual credentials in the Qeasy adapter.
• Request Structure: Wangdiantong takes shop_no, start_time/end_time, status as input parameters; Kingdee uses FormId (e.g., SAL_OUTSTOCK) + FieldKeys + FilterString for queries.
• Response Structure: Both are JSON arrays with pagination cursors. Wangdiantong supports page number/page size, while Kingdee supports Limit/StartRow.
• Pagination/Incremental Mode: Wangdiantong business documents mainly use modified_time time window for incremental sync; Kingdee uses FModifyTime or document number range for incremental sync; master data is fully synced initially and then incrementally by FModifyTime thereafter.

Typical Field Mappings

How to Configure on Qeasy

In the Qeasy Data Integration Platform, both Wangdiantong and Kingdee Cloud Galaxy have official adapters, requiring only selecting source/target systems and filling in credentials.

• Adapter: The platform has built-in "Wangdiantong · Enterprise Qimen" and "Kingdee Cloud Galaxy" adapters, encapsulating signature, login, and pagination logic.
• Field Mapper: In the strategy canvas, complete the four types of mappings (1:1, function, mapping table, constant) from source fields to target fields by dragging; the AfterSourceInvoke hook can inject custom logic such as shipping fee line splitting.
• Encoding Mapping: The four types of mapping tables (material/customer/warehouse/organization) can be initialized by uploading Excel, and the platform will automatically query by primary key; missing codes will be written to the failure record table and trigger alerts.
• Scheduling: The platform provides cron expressions and staggered peak configuration. Maintenance strategies such as deleting 90-day-old data can be scheduled to run at 02:00 daily during off-peak hours.

Cross-Solution Practical Points

1. Master Data First: The material (M) strategy must go live before business strategies; otherwise inbound and outbound operations will fail in bulk due to missing material codes.
2. Query Preloading Is Key: Although querying Kingdee receiving notice (L) and querying inbound orders (K) do not generate downstream documents, they provide the lookup data source for strategies such as C/D and must run first.
3. Document Types Distinguished by Constants: Sales outbound, consignment, transfer, and other inbound/outbound are different FBillTypeIDs on the Kingdee side; do not reuse the same code.
4. Shop Equals Customer, Warehouse Equals Organization: This is the most common confusion point in retail e-commerce; two independent mapping tables must be maintained.
5. Incremental Window Set by Business Volume: When daily document volume is high, the incremental window is recommended to be 15-20 minutes to avoid exceeding the single-pull limit.
6. Shipping Fee Line Splitting Implemented by Hook: When post_amount > 0, append a virtual spec code x0001 to the detail line through AfterSourceInvoke to avoid unbalanced total document amount.

Pitfall Review

• Pit 1: Material Codes Not Synchronized in Advance. In multiple client projects, it was discovered after business strategies went live that Wangdiantong products could not be found in Kingdee, causing bulk failures. The safe approach is to run the material strategy once in full first, then start business strategies.
• Pit 2: Timezone Inconsistency Causes Date Offset. Wangdiantong defaults to UTC+8, while Kingdee follows server timezone. When crossing timezones, FDate will be off by one day. Be sure to unify timezone configuration in the adapter.
• Pit 3: Shop and Customer Mapping Confusion. Pushing shop_name directly as a customer results in accounts receivable being assigned to the wrong organization. Two sets of mappings for sales organization and customer must be distinguished.
• Pit 4: Return Orders Not Linked to Original Sales Orders. src_trade_no is not written to F_wk_wdtysdh, making subsequent reverse lookup impossible. A truncation function needs to be added to the main table mapping.
• Pit 5: 90-Day Deletion Strategy Mistakenly Deletes In-Progress Data. If deletion is based on updated_time while tasks are still retrying, documents will be lost. It is recommended to filter by the dual condition of "completed and over 90 days".

When to Use

This tutorial applies to e-commerce retail, multi-organization multi-store scenarios where Wangdiantong serves as the front-end WMS/ERP and Kingdee Cloud Galaxy serves as the financial supply chain mid-platform. If an enterprise uses only a single ERP, or Wangdiantong and Kingdee are both privately deployed with extremely small document volume, directly using a database intermediate table is sufficient without this solution; conversely, whenever cross-system synchronization of the four major document types (sales, purchase, inventory, return) is involved, the 23-strategy framework of this tutorial should be followed for implementation.