One-to-One Sync from Jushuitan Sale-Out Orders to Chanjet T+ Sale Delivery

What this strategy solves

Retail merchants often run their online stores on Jushuitan while keeping finance and inventory on Chanjet T+. Every confirmed sale-out order must land as a T+ sale delivery voucher so reconciliation, stock accounting and invoicing can proceed. In one customer engagement we incrementally pulled sale-out orders for a specific retail shop and wrote them one-to-one into T+ — no merging — so each voucher stays traceable back to its source order.

Data flow and field mapping

Flow: Jushuitan Qimen → Qeasy Data Integration Platform → Chanjet T+.

The platform's data hub does two jobs in the middle: it persists the source payload, and it powers the _findCollection lookup that resolves shop_name → short_name before writing the T+ voucher.

Key field mapping (header)

The source request itself carries two filters: status=Confirmed (only out-confirmed orders) and shop_id=16288585 (only the retail shop), which keeps the pipeline free of irrelevant records.

How to configure on Qeasy

1. Source QUERY node: pick jushuitan.saleout.list.query, POST. Use {{LAST_SYNC_TIME|datetime}} for start_time, {{CURRENT_TIME|datetime}} for end_time, date_type=2 (out time), and pin shop_id to the retail shop.
2. Target EXECUTE node: pick /tplus/api/v2/saleDelivery/Create, POST, dataKey=dto.
3. Field mapping: configure per the table above. Customer uses _findCollection against the Jushuitan Shop Query strategy, keyed by shop_name, returning short_name.
4. Line mapping: SaleDeliveryDetails takes items directly. Drill into the sub-structure and map inventory code, quantity, unit price, etc. per T+'s detail spec.
5. Write mode: enable "do-not-merge write" so each source order produces exactly one target voucher.
6. Dependencies and scheduling: the Shop Query strategy must run first. Schedule the source at 03:49 daily and the target at 04:23 daily to leave a buffer.

Implementation steps

1. Incremental start point: on first go-live, rewind start_time to a fixed date (e.g., the day before cutover) to backfill the confirmed orders, then switch to {{LAST_SYNC_TIME}} and roll forward daily.
2. Run dependencies first: the Shop Query strategy must complete before this one; otherwise _findCollection finds no short_name and the customer field ends up blank.
3. Frequency: once per day. Chain source (03:49) → target (04:23) so the shop data is ready.
4. ExternalCode dedup: concatenating io_id + "+1" keeps the code unique and avoids clashing with T+ internal codes.
5. Monitoring and retries: Qeasy uses io_id as the idempotency key; failed vouchers can be retried by ExternalCode without double-posting.

Pitfalls and lessons

• The window between start_time and end_time must not exceed 7 days. Jushuitan's API caps the range. The safe approach is to keep the window to one day and let the scheduler advance it.
• Don't blindly fall back to io_date when io_date_new is empty. Detect the empty case first and only then apply the conversion, or the voucher date will drift.
• +1 is string concatenation, not addition. Verify the platform treats it as text; otherwise the ExternalCode loses characters and T+ rejects the payload.
• Don't reverse the dependency order. If Shop Query hasn't finished, _findCollection returns null and the customer field goes blank, failing the batch. Put the dependency on the schedule chain so Qeasy triggers them in order.
• Don't confuse Confirmed with Cancelled. Cancelled orders also carry io_id and will either post as negatives or be rejected. Filter them at the source.

When to use and when not to

Use when: one shop per retail customer, moderate order volume, strict 1:1 traceability, and reconciliation requires vouchers to mirror source orders one-to-one. Don't use when: multiple out-orders must be merged into one invoice, aggregation by customer/day is required, or the business needs warehouse splits or other T+ voucher types — those call for a separate aggregation strategy.