Sync of After-Sales Refund Orders from Jushuitan to DingTalk Return-and-Photo Confirmation Form with Waybill Echo

What This Strategy Solves

"Ship a sample, then return it" is a common after-sales flow in e-commerce: the customer returns the goods, the warehouse confirms, and operations must run a Return-and-Photo Confirmation form through DingTalk, then echo the final waybill number back to the after-sales order in Jushuitan. Running two systems by hand easily leads to missed or mistyped entries. This strategy is delivered on the Qeasy data-integration platform. It uses one single link to incrementally pull after-sales refund orders from Jushuitan into a DingTalk approval instance and then closes the loop by writing the waybill number back.

Data Flow and Field Mapping

The overall direction is: Jushuitan (after-sales order) → Qeasy middleware layer → DingTalk (Return-and-Photo Confirmation process instance), followed by a second hop that echoes the waybill number back to Jushuitan. The source endpoint is /open/refund/single/query (POST, paginated with a time window). The target endpoint is topapi/process/instance/comment/add (POST, DingTalk approval flow comment / field update).

Key field mapping table:

How to Configure It on Qeasy

1. Source collector: pick the Jushuitan "after-sales order query" interface. Set page_size to 50, date_type to 0, and bind modified_begin / modified_end to the Qeasy date variables {{DAYS_AGO_1|datetime}} and {{CURRENT_TIME|datetime}} instead of hard-coded values.
2. Target executor: pick DingTalk's "process instance comment / field write" action. Configure the approval template code and pass the after-sales order id and line items as the request object.
3. Centralized code mapping: keep product codes, warehouse codes, and customer codes in a single mapping table that Qeasy can reference inside the strategy, instead of scattering them across many strategies.
4. Echo executor: once the DingTalk approval reaches the "shipped" node, Qeasy either listens to a DingTalk callback or polls again on schedule and writes the waybill number back into the extension field of the Jushuitan after-sales order.
5. Idempotency switch: turn on the idCheck=true flag from the source metadata. Qeasy will deduplicate by as_id to avoid creating duplicate process instances.
6. Header vs. lines in stages: this strategy first creates the process instance from the header, then appends the line-item fields through comments. Qeasy's "staged write" option lets you toggle the two phases separately.

Implementation Steps

We split the rollout into four steps to avoid crushing the warehouse and approvers with one big full sync.

1. Initialize the increment anchor: run a full pull once and pin modified_begin to 00:00 of the previous day. Historical documents only generate DingTalk process instances, no waybill echo.
2. Configure a gray launch: start with one to three warehouses or one customer-service group to validate that process instances are correct and the echo fields align.
3. Turn on the production schedule: source at 1-59/9 7-23 * * * (every 9 minutes), target at 1-59/10 7-23 * * * (offset by one minute to avoid write spikes); stop running at night to reduce noise.
4. Full recheck and echo backfill: on a fixed day every month, run a full reconciliation script that scans for unclosed documents and backfills missing waybill numbers. Keep increment and full-recheck running as twin tracks.

Lessons from the Field

1. Source rejects windows longer than 7 days: when modified_begin and modified_end are more than 7 days apart, the Jushuitan endpoint errors out. The safe pattern is to add a "window validation" pre-node inside Qeasy so oversized windows are auto-chunked.
2. Forgetting to lock date_type causes missed documents: the default is modified time, but operations staff editing fields in Jushuitan can refresh that timestamp. Switch to created time or confirmation time when needed and expose it as a parameterized config in Qeasy.
3. Duplicate DingTalk process instances: without deduplication, the same after-sales order is re-fetched every 9 minutes and a new process is created each time. Always enable idCheck and let Qeasy's storage layer use as_id as the unique key.
4. Echoing the waybill too early: if you echo the waybill before the DingTalk approval reaches the "shipped" node, Jushuitan will receive an empty value. The safe pattern is to drive the echo from an event-based DingTalk status callback, not by polling for status.
5. Public cloud rate limits: a 9-minute interval feels sparse, but when several warehouses run in parallel the cumulative QPS can still trip the source rate limiter. Qeasy recommends staggering multiple strategies across the hour and lowering page_size when necessary.

When to Use It and When Not To

Use it when: an e-commerce retail after-sales order must bind tightly to an external approval or logistics receipt; the document schema is stable and the modification frequency is controllable; you need a lightweight close-the-loop (waybill echo). Do not use it when: the after-sales schema changes often, the source endpoint is rate-limited and yet you need near real-time, or the approval form is complex and needs humans to fill in fields before the echo — in that case clean up the master data first, then integrate.