Return Request to Other Inbound Unconfirmed in Jushuitan: A Hands-On Tutorial for One Strategy

What This Strategy Solves

A retail client had a persistent bottleneck at the boundary between two systems: store-level returns were filed in the ecommerce ERP, but when the goods reached the central warehouse, the WMS needed an Other Inbound document in Jushuitan that warehouse staff could verify physically before confirming in the system. The strategy therefore only writes the return request into Jushuitan as Other Inbound (unconfirmed), with no automatic confirmation. This tutorial uses that single strategy as a worked example, showing how the Qeasy data integration platform can reliably deliver Kingdee Cloud return requests to the Jushuitan jushuitan.otherinout.upload endpoint.

Data Flow and Field Mapping

The flow is one-directional: Kingdee Cloud (source) → Qeasy integration platform (middleware) → Jushuitan (target).

The source side pulls return requests via Kingdee's executeBillQuery. The middleware handles code mapping, field restructuring, and idempotent deduplication. The target side calls jushuitan.otherinout.upload to create the Other Inbound record. The key fields are mapped as follows:

Business Meaning	Kingdee Cloud (Source)	Jushuitan (Target)	Notes
Document Number	FBillNo	external_id	Source number used as idempotency key
Document Inner ID	FID	—	Dedup in middleware
Line Inner ID	FEntity_FEntryID	—	Dedup in middleware
Source Document No.	FSRCBILLNO	—	Traceability
Date	FDate	io_date	Business date
Customer Code	FRETCUSTID_Fnumber	drp_co_name	Customer / return party
Warehouse	FStockID_Fnumber	wms_co_id / warehouse	Warehouse code mapping
Material Code	FMaterialId_Fnumber	sku_id	Centralized material code mapping
Quantity	FQty	qty	Quantity field
In/Out Type	—	type	Fixed as `in`
Auto Confirm	—	is_confirm	Fixed as `0`
Main Warehouse Type	—	warehouse	Default `1`

The core of the middleware is centralized code mapping for warehouses, customers, and materials. None of these mappings are hardcoded inside individual strategies, so adding a new store or changing a warehouse only requires editing one place.

How to Configure It in Qeasy

There are four configuration blocks to focus on:

Source endpoint: On the Kingdee Cloud side, use executeBillQuery with FBillNo as the query field, FEntity_FEntryID (line inner ID) as the primary key, idCheck enabled, and buildModel disabled — the field structure is stable, and rebuilding the model would overwrite existing mappings.
Target endpoint: On the Jushuitan side, use jushuitan.otherinout.upload. Hardcode is_confirm to 0 (unconfirmed), type to in, and warehouse to 1 (main warehouse). wms_co_id uses {{FStockID_Fnumber}} for variable interpolation against the mapping table.
Middleware mapping: Use FEntity_FEntryID as the line-level idempotency key and compose external_id as {FBillNo}-{FEntity_FEntryID} so the header-line relationship is not flattened on the target side.
Exception handling: When Jushuitan returns a failure, Qeasy retries automatically, but the source side must not re-push during the retry window. The source query filter must therefore carry both a timestamp and a document status check.

Implementation Steps

We run this in three phases:

Incremental starting point: Pick a historical anchor in Kingdee Cloud (for example, the last 7 days of return requests) as the start point for this integration. Qeasy supports both a fixed anchor and an incremental cursor in parallel.
Full backfill: On first go-live, manually trigger a one-time backfill to cover everything before the anchor. Once the backfill completes, the system switches automatically to cursor mode.
Schedule frequency: The source polls every 15 minutes (1-59/15 7-23 * * *) during business hours; the target writes every 5 minutes (*/5 7-23 * * *) so writes outpace reads and no backlog builds up. Nothing runs overnight, which avoids wasted traffic.

Lessons Learned from the Field

Auto-confirm is on by default: The jushuitan.otherinout.upload endpoint treats is_confirm as 1 by default, which means the document is confirmed as soon as it is uploaded — before warehouse staff has even checked the goods. The reliable fix is to hardcode is_confirm to 0 in the strategy and let warehouse staff confirm manually in Jushuitan.
One-to-many warehouse mapping: FStockID_Fnumber is a single field in Kingdee, but in Jushuitan it has to be split into wms_co_id (sub-warehouse) plus warehouse (main / sales-return / inbound / defect warehouse). Passing only one field silently drops information.
Document number alone is not a fine-grained idempotency key: Using FBillNo as the idempotency key causes Jushuitan to filter out multiple line items on the same return document as duplicates. Compose external_id as FBillNo + FEntity_FEntryID instead.
Cross-midnight documents get dropped: A fixed window like "yesterday 00:00 to today 00:00" will miss documents that cross midnight. A sliding window of "last successful timestamp → current time − 2 minutes" is more robust.
Rebuilding the model overwrites mappings: When the field structure is stable, keep buildModel turned off. Otherwise Qeasy will rebuild the model and silently overwrite the field mappings you have carefully maintained — which is extremely hard to spot while debugging.

When to Use This Strategy — and When Not To

Use it when: returns need physical verification before system confirmation; ecommerce ERP and WMS are separate with inconsistent coding systems; daily volume is in the few thousands and real-time, sub-second sync is not required.

Do not use it when: the business needs Jushuitan to auto-confirm and immediately affect sellable inventory (use an auto-confirm strategy instead); or when return amounts need to flow back into Kingdee Cloud for financial accounting — that requires a separate reverse-sync strategy, which is out of scope here.