Syncing Amazon Orders from LingXing ERP to Kingdee YXC Sales Outbound: A Hands-On Tutorial

What This Strategy Solves

Sellers running Amazon multi-channel operations all share the same pain: orders carry one set of semantics in the ERP and another in the finance system. We once worked with a cross-border e-commerce team handling several hundred Amazon orders a day in LingXing ERP, but their warehouse and finance teams needed sales outbound documents in Kingdee YXC. The two sides never agreed on codes, products, or customers, and month-end reconciliation was done manually.

This strategy does one focused thing: it pulls Amazon multi-channel sales orders from LingXing ERP on a scheduled cadence, transforms them into Kingdee YXC sales outbound documents, and sets operation_key to the audit state so the documents flow directly into the outbound/audited pipeline. In real projects we use the Qeasy data integration platform (轻易云) to carry this entire chain—source extraction, intermediate mapping, and target write—inside a single strategy.

Data Flow and Field Mapping

The flow is unidirectional: LingXing ERP (Amazon orders) → Qeasy integration platform (intermediate mapping) → Kingdee YXC (sales outbound).

The source side calls LingXing ERP's order query API, pulling Amazon order lists incrementally by start_date / end_date ranges, with amazon_order_id as the primary key and offset / length as pagination parameters. The target side calls Kingdee YXC's sales outbound API, with id as the primary key, and requires an operation_key to control document status.

Key field mappings look roughly like this:

One thing worth highlighting: header and body fields are processed in staged phases in Qeasy—the header fields land first and pass validation, then body line items are looped in. This is a common pattern among Qeasy customers, avoiding the situation where a single large payload fails and you cannot tell which line caused it.

Configuring in Qeasy

In the Qeasy integration platform, configuring this strategy breaks into three blocks.

Source configuration: Select the LingXing ERP platform, choose API /order/amzod/api/orderList, method POST. The incremental starting point uses a time macro {{DAYS_AGO_s10|date}}—pulling from 10 minutes before the current time, with the end time as {{CURRENT_TIME|date}}. date_type defaults to 1 (purchase time). Pagination parameters offset and length go through a loop, advancing one page at a time until the response is empty.

Target configuration: Select Kingdee YXC V2, choose API /jdy/v2/scm/sal_out_bound, method POST. bill_source is hardcoded as ISV, and operation_key is hardcoded as audit—both are constants. bill_no binds directly to the source amazon_order_id, and bill_date binds to purchase_date_local with date formatting applied.

Intermediate mapping layer: This is where things most often go wrong. Customer IDs, product codes, and currencies almost never match one-to-one between the two systems, so code mapping is mandatory. The safe approach is centralized mapping management—store customer and product mapping tables in Qeasy's mapping tables, and have the strategy only reference them. When business rules change later, you update the mapping tables, not the strategies.

Implementation Steps

We recommend a three-step rollout:

Step 1: Calibrate the incremental starting point. In a test environment, first use a fixed start_date to pull a batch of historical orders and verify field mappings and code conversions. Do not rush to enable scheduling here—manually trigger runs first until everything works.

Step 2: Trigger a full backfill. Once mappings are confirmed correct, change the incremental starting point to {{DAYS_AGO_s10|date}} and run a full backfill to catch up on historical orders that were never synced. After the full run completes, switch to normal scheduling.

Step 3: Enable scheduling. Set the source schedule to 7-59/15 7-23 * (starting at 7:07, every 15 minutes, ending at 23:59), and the target schedule to 9-59/15 7-23 * (starting 2 minutes after the source to avoid racing). Running the two schedules with offset timing is a typical dual-track approach with incremental and full modes—daily incrementals are handled by the schedule, and abnormal cases trigger manual full backfills.

Lessons from the Field

1. Passing through customer codes without mapping. A classic mistake is stuffing LingXing's sid directly into Kingdee's customer_number, which causes Kingdee to fail finding the customer and the document gets stuck. Always do a lookup-based conversion in the mapping layer.
2. Forgetting or mistyping operation_key. This field controls whether the document is auto-audited; leaving it empty means draft, while audit means audited. We have seen cases where case or spelling errors caused all documents to stay in draft state.
3. Choosing the wrong time zone for date_type. LingXing's API supports three time types (site time, Beijing time, UTC), with 1 defaulting to site time. If your business semantics rely on Beijing time, change it to 2, otherwise order dates can be off by a day or more.
4. Body line items exceeding the per-document limit. Kingdee YXC's sales outbound document has a limit on body line count. For orders with many products, either split them in Qeasy first or confirm that your target system version supports large line counts.
5. Duplicate pushes during full backfill. Without idempotency control, full backfills produce duplicate documents. In Qeasy we use bill_no as the idempotency key, and the target interface has idCheck=true so duplicates are rejected—but expect the logs to fill up with red errors.

When This Fits and When It Does Not

Fits: Cross-border e-commerce businesses with high Amazon multi-channel order volume that need unified sales outbound and financial accounting in Kingdee; scenarios where order structure is relatively stable and product/customer master data already exists in Kingdee.

Does not fit: Scenarios requiring real-time sync for frequent order status changes (this strategy runs at 15-minute granularity); scenarios where Kingdee has not completed product or customer master data initialization (nowhere for code mapping to look up); scenarios requiring logistics status to be written back to LingXing (this strategy is unidirectional).