Purchase Inbound Order (Subcontracting) Sync Solution: From Kingdee YXC to WangdianTong

What This Strategy Solves

In subcontracting processing, when raw materials are sent to suppliers and finished goods are received back, a stable document channel between ERP and WMS is essential. One retail enterprise we worked with faced exactly this issue: subcontracting inbound orders approved in Kingdee YXC never updated inventory in WangdianTong, subcontracting warehouse inbound quantities didn't match, and after three months a stocktake revealed significant discrepancies. We used the Qeasy Data Integration Platform to handle this strategy, incrementally pushing Kingdee YXC subcontracting purchase inbound orders to WangdianTong QiM. The core goal was to get the special "subcontracting warehouse stock inout order" document type flowing correctly, keeping it separate from standard purchase inbound orders.

Data Flow and Field Mapping

Data flow is unidirectional: Kingdee YXC V2 → Qeasy DataHub → WangdianTong QiM. The source uses a QUERY-type GET interface /jdy/v2/scm/pur_inbound to fetch documents, while the target uses a WebAPI-type POST interface wdt.vip.wms.stockinout.order.push to push them.

Key header field mapping:

Detail rows are processed in a loop. Typical mappings include: material_number → spec_no, qty → num, tax_price → tax_price, batch_no → batch_no, producedate → production_date, validdate → expire_date, etc. The warehouse code must be extracted from the detail rows—this is a Kingdee YXC data structure characteristic; the header doesn't carry a warehouse field.

Configuring on Qeasy

When configuring this strategy on the Qeasy platform, we typically split it into three parts: source interface, target interface, and field mapping.

Source Interface Configuration: Select API /jdy/v2/scm/pur_inbound, method GET, page size default 10 (max 100). Key parameters include enable=1 (only available documents), bill_status=C (only approved), and modify_start_time / modify_end_time using timestamp millisecond values for the incremental window.

Target Interface Configuration: Select API wdt.vip.wms.stockinout.order.push, method POST. Two fixed constants are hardcoded: order_type=2, auto_check=1. api_outer_no references {{bill_no}}, and warehouse_no references the first detail row's {{material_entity.material_entity_stock_number}}.

Centralized Code Mapping Management: For warehouse code and material code mappings, many clients build a separate master data mapping table (placed in Qeasy's "Code Mapping" node) rather than scattering mappings across each strategy. This way, when adding a new subcontracting warehouse or material, only one table needs maintenance, and all referencing strategies automatically pick it up. We recommend a phased approach for header and detail mappings: get the header working first, then handle the details.

Implementation Steps

Step 1: Determine Incremental Starting Point. Before strategy launch, use full-data mode to backfill historical approved documents once, recording the backfill end time T0 as the incremental starting point. The "Full Trigger" button in Qeasy can complete historical data initialization with one click, then automatically switch to incremental mode.

Step 2: Configure Schedule Frequency. Since business operations are concentrated during the day with little activity at night, we adopted the schedule rule */10 8-22 * * *: every 10 minutes from 8:00 to 22:00 daily. This ensures timeliness without wasting resources on nighttime empty runs.

Step 3: Monitoring and Exception Handling. In the first week after launch, focus on three types of exceptions: warehouse code not found (meaning warehouse master data isn't synced), material code not found (missing material master data), and subcontracting warehouse type mismatch (warehouse in WangdianTong incorrectly configured as a regular warehouse). Qeasy's monitoring dashboard can aggregate by error type, making localization relatively quick.

Step 4: Dual-Track Incremental and Full Sync. Daily operations run on incremental mode (based on modify_start_time/modify_end_time), but retain full-data backfill capability. A common Qeasy client pattern is: run a "last 7 days full comparison" every Sunday morning as a reconciliation check against incremental sync, preventing missed documents.

Lessons Learned

1. Wrong warehouse code location. Kingdee YXC's header doesn't carry a warehouse field; the warehouse code is hidden in the detail row's material_entity_stock_number. If you take it from the header following conventional logic, the pushed value will be empty. This is a common pitfall—the safe approach is to explicitly write "take from the first detail row."

2. Mixing subcontracting and regular warehouses. If the same strategy doesn't filter by business type, it will also push standard purchase inbound orders to the subcontracting warehouse interface, causing WangdianTong errors or inventory confusion. Subcontracting purchase inbound orders and standard purchase inbound orders should be distinguished by transtype, or simply split into two separate strategies (P4-236 for standard, P4-238 for subcontracting).

3. Repeated push causes update instead of creation. WangdianTong uses api_outer_no as the external order number for deduplication; pushing the same document again updates the original rather than throwing an error. If the source document has changes but the status hasn't changed (e.g., only remarks were edited), the incremental timestamp might not capture it, causing data drift between the two systems.

4. Missing batch management fields. When materials have batch management enabled, three fields must be passed: batch_no, production_date, and expire_date. Missing any one causes WangdianTong to reject the document. Such validation is strict, so during integration testing, materials with batch management should be run separately.

5. Accidentally turning off auto_check. auto_check defaults to 1 (auto-approve). If accidentally changed to 0, pushed inbound orders remain in "pending approval" status, inventory doesn't update, and the business side thinks the integration is broken.

Applicable and Non-Applicable Scenarios

Applicable Scenarios: Enterprises with subcontracting processing business that need to sync subcontracting purchase inbound orders between ERP (here Kingdee YXC) and WMS (here WangdianTong QiM), where the target WMS supports the subcontracting warehouse stock inout order API.

Non-Applicable Scenarios: Pure self-owned factory inbound (should use standard purchase inbound order strategy), target WMS doesn't support subcontracting warehouse types (need to initialize warehouses via master data strategy first), source ERP doesn't carry business type fields (cannot distinguish subcontracting from standard, recommend doing master data governance first).