Practical Guide: Syncing After-sales Orders from Jushuitan to Chanjet Red-letter Sales Orders

What This Strategy Solves (Scenario and Value)

In a multi-channel retail business, after-sales return documents are scattered across the front-end e-commerce system (here, Jushuitan), while finance and inventory books are kept in the ERP (here, Chanjet T+). Finance needs to reconcile red-letter sales orders every month, and stores need to reduce inventory and receivables when returns come in. If the team relies on manual export and re-entry, the process is slow and error-prone—especially for partial returns, multi-batch arrivals, and cross-month reversals. We use the Qeasy Data Integration Platform (referred to below as Qeasy) to handle this: convert Jushuitan after-sales documents into red-letter sales orders in Chanjet T+ according to predefined rules, achieving same-day closure of return data.

Data Flow and Field Mapping

The overall direction is B_TO_A: Jushuitan (source) → Qeasy middle layer → Chanjet T+ (target).

Key field mapping table (only business-critical fields are listed; actual field names follow the source system):

Field mapping is the make-or-break of whether this strategy can run stably for three months. A common pattern among Qeasy customers is "centralized mapping management": keep SKU↔inventory code and store↔customer code in a single master data table, and have the strategy only reference it instead of maintaining its own copies.

How to Configure in Qeasy

When configuring this strategy in Qeasy, the typical points are:

1. Datasource registration: connect to Jushuitan open APIs and the corresponding sales APIs in Chanjet T+; credentials for both sides are stored in credential management and injected at runtime.
2. Pull rule: pull Jushuitan after-sales orders by "modification time > last successful sync time"; the first full pull needs a separate trigger, then switch to incremental.
3. Field mapping: configure field correspondences in the strategy canvas, attach a built-in "negate" function to the quantity field so that the return quantity is flipped to negative and lands in the target quantity column.
4. Header and body staged processing: this is another typical pattern among Qeasy customers—"header and body staged". First write the header (customer, warehouse, document number, remarks), then the body (line items); a failure at any stage does not corrupt the target document.
5. Write mode: red-letter sales orders are written through Chanjet T+'s "red-letter document" interface rather than creating a blue-letter order and then reversing it; the former keeps accounting cleaner.
6. Failure handling: document-level errors fall into an exception queue, the strategy does not halt; a document that fails three times is escalated to manual handling.

Implementation Steps

We recommend a three-step approach: "incremental anchor → full trigger → scheduling cadence".

• Stage 1: Set the incremental anchor. In Qeasy, set the initial last_sync_time, typically 7 days before the deployment day, which both covers unclosed historical documents and avoids pulling too much history at once.
• Stage 2: Full trigger. Perform a cold start on the books and sync all existing unclosed after-sales orders at once; once cold start is done, switch to incremental. Cold start should be scheduled during off-peak hours such as early morning, with a batch size of "commit every 200 documents".
• Stage 3: Scheduling cadence. After-sales returns have a "delayed arrival" characteristic—customers often submit applications first and return in batches. Therefore the scheduling cadence is suggested at every 15 minutes, which neither overwhelms the source system nor blocks same-day closure. A common Qeasy customer pattern is "incremental and full dual-track": daily incremental every 15 minutes, with a fixed weekly "sliding 7-day window" reconciliation full pull as a safety net for missed documents.

Pitfall Recap

• Pitfall 1: Quantity sign not flipped. If positive values land in the target system, the result is a "blue-letter sales order" instead of a red-letter one, and both inventory and receivables go the wrong way. Safe practice: explicitly apply "negate" in the mapping layer, and add an assertion "target quantity < 0".
• Pitfall 2: Store not mapped to customer. The customer in an after-sales order is at the "store" level; writing it directly as an ERP customer will fail to find the master record. Safe practice: use "centralized mapping management" to maintain a store↔customer lookup table in advance, and run another strategy (such as "store → business partner") to populate it before this strategy starts.
• Pitfall 3: Incremental anchor drift. If someone manually backfills a 3-month-old document in the source system, the modification-time-based incremental will not catch it. Safe practice: also maintain a "document-number deduplication table"; when a document number is missing from the target, force a re-pull.
• Pitfall 4: Batch chaos for partial returns. A single after-sales order returned in multiple batches updates the modification time only at the last batch; intermediate batch arrivals will be missed. Safe practice: in Qeasy, use document number + line number as the unique key, rather than deduplicating by document number alone.

Applicable and Non-applicable Scenarios

Applicable: e-commerce retail, wholesale stalls, and other multi-channel businesses that need to sync front-end after-sales orders to the ERP as red-letter sales orders on a daily basis for inventory reduction and receivable adjustment. Not applicable: industries requiring strict batch/serial-number traceability such as pharmaceuticals or medical devices, and processes where returns must pass quality inspection before a red-letter order is issued—these scenarios need an additional inspection-status gateway in the middle layer.