Sales Order Amazon Backfill Sync: A Practical Guide from LingXing ERP to Kingdee Cloud

What This Strategy Solves

In cross-border e-commerce, LingXing ERP is usually the source of truth for order fulfillment, but occasional delays, network jitter, or API rate limits can cause some Amazon orders to fail to flow into the domestic ERP in time. Kingdee Cloud, as the final landing point for finance and inventory, will end up with an inconsistent state over time: shipments have gone out, stock has been deducted, yet the outbound delivery note was never generated.

The core value of this strategy is to take confirmed-shipment orders in LingXing ERP that have not yet been pushed to Kingdee, perform a targeted backfill by store and time window, and generate sales outbound delivery notes on the Kingdee side, closing the loop across order flow, inventory flow, and finance flow. In our real projects, we typically use the Qeasy Data Integration Platform to host this as an independent backfill job that runs in parallel with the regular full/incremental sync strategies.

Data Flow and Field Mapping

The overall chain is one-way: LingXing ERP (source) → Qeasy middleware layer → Kingdee Cloud (target).

The source uses POST /erp/sc/data/mws/orderDetail to pull order details. It is essentially a time-window query, with key inputs being start_date, end_date, date_type, and store ID store_ids. The date_type semantics are explicitly described in the source material: 1 = order time (site time), 2 = order modification time (Beijing time), 3 = platform update time (UTC), default 1.

The target calls the Kingdee batchSave interface to generate a sales outbound delivery note. The key field mapping is:

Idempotency key design is critical: both number and id use the {{amazon_order_id}}-{{sid}} composite key, so Kingdee can deduplicate by document number on repeated requests, avoiding duplicate outbound delivery.

How to Configure on Qeasy

In the Qeasy Data Integration Platform, we typically configure this strategy as one-in-one-out: a read model on the source side and a write model on the target side, connected by a field mapping connector.

Source configuration: select QUERY for api, also set effect to QUERY, and enable idCheck so the platform deduplicates by amazon_order_id-sid and ensures each order is processed only once even if pulled multiple times. With autoFillResponse enabled, response fields automatically flow into the data context, eliminating the need to manually declare them in downstream mapping.

Target configuration: select EXECUTE for api, also enable idCheck, and reuse the same composite expression for number to ensure write-side idempotency. The date field uses Qeasy's _function LEFT(...) to truncate, preventing the raw shipment_date from carrying HH:mm:ss and triggering Kingdee validation errors.

Customer code mapping is where we most often trip up. On Qeasy, we recommend two approaches: first, create a dedicated code-mapping table that centrally maintains the Amazon buyer ID and the Kingdee customer internal code, and use the field mapping node's lookup transformation; second, write the mapping logic directly in a Qeasy script node, suitable for cases with clear rules and a small customer base. We have used both, and the first approach is easier to audit later.

Implementation Steps

Unlike routine sync, a backfill strategy needs careful control of trigger timing and frequency. We typically roll out in three phases: phase one, a full historical backfill to recover all missed orders at once; phase two, switch to incremental, scanning the previous day's data daily by store and time window; phase three, as a safety net, run another longer-cycle scan (for example every three days or weekly) to catch anything missed in the first two.

Full phase: set start_date to the business go-live date and end_date to the day before backfill launch, splitting into multiple parallel tasks per store to avoid triggering LingXing API rate limits due to oversized single responses.

Incremental start point: choose date_type=2 (order modification time, Beijing time), starting from midnight of the backfill launch day, rolling forward at 2-4 AM daily to pull orders whose modification time falls in the window.

Scheduling frequency: we recommend scheduling it during non-peak hours on workdays (e.g. 2-4 AM) to reduce source-system pressure. Qeasy's scheduling expression supports cron, with a typical configuration such as 0 0 2 * * ?.

Lessons Learned

First, picking the wrong date type. date_type defaults to 1 (site time); if the business team actually cares about order changes, picking the wrong one pulls back a lot of irrelevant data. We recommend documenting the semantics and business interpretation of date_type in the strategy notes on Qeasy.

Second, writing dates with HH:mm:ss directly into Kingdee. Kingdee's FDate validation is strict and will reject values carrying HH:mm:ss. The safe approach is to explicitly truncate with _function LEFT('{{shipment_date}}', 10), not relying on target-side auto-cleanup.

Third, customer code not mapped. Pushing the Amazon buyer ID directly into FCustomerID will inevitably cause Kingdee to error. We have seen the typical mistake of treating the Amazon buyer_email as the Kingdee customer code, which fails the entire batch. The correct approach is to go through the code-mapping layer first.

Fourth, idempotency key designed too narrowly. Using only amazon_order_id in a multi-store scenario causes key collisions; sid must be concatenated in. The source material also explicitly uses the composite key.

Fifth, backfill job colliding with routine sync. If orders pulled by the backfill strategy have not yet generated documents in Kingdee, the subsequent routine sync strategy will try to push them again, causing duplicates. The safe approach is to sequence this backfill strategy ahead of the routine sync on Qeasy, or add an "already-existing document number, skip" check on the routine sync side.

Applicable and Non-Applicable Scenarios

Applicable: cross-border e-commerce fulfillment with occasional missed orders, scenarios requiring targeted backfill by store and time window, with idempotency and traceability requirements. Not applicable: scenarios with large order structure differences requiring complex business transformation (such as multi-store order splitting, bundled SKUs). These should use a dedicated transformation strategy instead.

Note on the Repeated Section

A backfill strategy is a safety net, not the main pipeline. It fits businesses with relatively stable document structure and a clear backfill window (typically 1-7 days); it does not fit scenarios with very high real-time requirements (minute-level) or frequently changing master data. The latter should directly improve the stability of the main sync strategy rather than relying on backfill.