Manual Order Sales Outbound Sync in Practice: Customer Lookup and Phased Scheduling from Jky to Kingdee Cloud

What This Strategy Solves

In the supply chain of a retail enterprise, manual offline orders and online e-commerce orders follow two different identification logics: online orders map customers by shop code, while manual orders can only look up customer codes in Kingdee's master data by customer name. If the lookup is not designed properly, you will end up with the awkward situation of "documents pushed to Kingdee with the customer field empty, inventory not deducted, and financial reconciliation failing to match." We use the Qeasy Data Integration Platform to carry this link, with the goal of incrementally pulling Jky Qimen manual outbound documents into Kingdee Cloud by consignTime, looking up customers by name, and automatically identifying returns.

Data Flow and Field Mapping

Data flow: Jky Qimen (manual trade shipping data) → Qeasy middle layer → Kingdee Cloud SAL_OUTSTOCK.

Key field mapping (header):

Line items: source goodsDetail[] array is looped and mapped to target FEntity[]. Typical mappings: goodsNo/barcode/outerId → FMaterialId.FNumber, actualSendCount → FRealQty, sellPrice → FPrice, sellTotal → FAmount.

How to Configure on Qeasy

Source (Jky Qimen)

• API: jackyun.tradenotsensitiveinfos.list.get (WebAPI/QUERY), primary key tradeNo, enable idCheck.
• Incremental window: startConsignTime = {{HOURE_AGO_1|datetime}}, endConsignTime = {{CURRENT_TIME|datetime}}, rolling by consignTime.
• Filter: tradeTypeList = 1,2,3,4,5,6,7,9,10,11,13,91,92,93,100, isDelete = 0.
• Required field: customerName (the only clue to identify a customer in manual orders — must be checked out).

Target (Kingdee Cloud)

• API: batchSave (EXECUTE, FormId SAL_OUTSTOCK), idCheck = true, primary key id.
• Customer: FCustomerID uses _findCollection find FNumber from 1c941bfd-177f-37ad-98f5-89f93b4085b6 where FName={{customerName}}. It depends on the "Kingdee Customer → Jky Customer" sync strategy to land customer master data in the hub first.
• Outbound type: tradeType='7' maps to 002 (return), otherwise 001 (normal outbound). Expression: _function CASE '{{tradeType}}' WHEN '7' THEN '002' ELSE '001' END.
• Material: line FMaterialId is mapped through "shop + SKU/goods code" against Kingdee material FNumber, supported by the material sync strategy.

Scheduling: source runs 1-59/7 7-22 * * *, target runs 3-59/7 7-22 * * *, staggered by 2 minutes to avoid read/write collisions.

Implementation Steps

1. Prerequisites: confirm that the "Kingdee Customer → Jky Customer" and "Kingdee Material → Jky Goods" master data sync strategies are running stably; otherwise _findCollection returns nothing.
2. Full-volume trigger: for the first go-live, perform a full backfill to complete historical manual orders; manually specify the startConsignTime/endConsignTime range and validate the target first in a test environment.
3. Incremental start point: after the full sync completes, switch the source to a rolling window of HOURE_AGO_1 / CURRENT_TIME and pull incrementally by consignTime.
4. Schedule rollout: source runs every 7 minutes between 7:00 and 22:00, target runs 2 minutes later, achieving a "header first, then lines" dual-track approach — a common pattern among Qeasy customers.
5. Closed-loop monitoring: configure failure retry and alerting on Qeasy. Build dedicated alert channels for FCustomerID lookup nulls, FMaterialId unmapped, and tradeType anomalies.

Lessons Learned (Pitfalls)

1. Customer name inconsistency is the biggest trap: Jky manual-order customer names often have spaces or aliases, while Kingdee master data uses standardized names, so the lookup returns empty. The safe approach is to make "customer master data sync" a hard prerequisite and maintain a centralized difference table — a typical Qeasy customer pattern of centralized encoding mapping.
2. Pushing line items without material code mapping: when FMaterialId cannot be resolved, the entire document fails to save in Kingdee. Decoupling material sync from outbound sync — headers first, then backfill lines — is a common practice.
3. Missing the tradeType return/exchange branch: without the CASE expression, all manual orders are treated as normal outbound, causing inventory and financial reconciliation to be off.
4. Incremental window set too narrow: only catching CURRENT_TIME at one instant will miss orders submitted across minute boundaries. Using HOURE_AGO_1 with a 1-hour overlap is more robust.
5. Source and target scheduled in the same minute: when both run on */7 simultaneously, network jitter easily causes duplicate writes. Staggering with 1-59/7 and 3-59/7 (2 minutes apart) is a lesson everyone who's been bitten learns.

Applicable and Inapplicable Scenarios

Applicable: offline/manually entered shipments that require customer lookup by name, using consignTime as the incremental basis, with returns requiring independent identification. Not applicable: standardized e-commerce platform orders (should use the [Online] strategy), scenarios where customers and shops are clearly bound without the need for lookup, or initial go-live phases without material master data support.