FBA Cost-Value Stream to Kingdee Cloud Staged Transfer-In: A Single-Strategy Walkthrough

What this strategy solves

In cross-border operations, FBA replenishment inbound is the entry action that pushes head-haul goods into the FBA warehouse. The "cost-value stream" behind it defines inventory value and feeds back into gross margin, reconciliation, and tax reporting. The source lives in one ERP (Lingxing), the accounting view lives in another (Kingdee Cloud), and the two do not share a table. This strategy picks the FBA replenishment inbound business type out of Lingxing's Amazon-action-dated cost stream and lands it as a staged transfer-in document in Kingdee, so finance has a traceable inbound voucher.

Data flow and field mapping

The flow is Lingxing ERP (cost-value stream source) → Qeasy middle layer (encoding / date / bill number conversion) → Kingdee Cloud (staged transfer-in document). The source side queries by month, the target side writes by document, and Qeasy sits in between handling filtering, calculation, and assembly.

How to configure it in Qeasy

In the Qeasy Data Integration Platform, this is a standard "source query → target write" pipeline. The configuration effort falls into four places:

1. Source data source: pick the Lingxing ERP platform, use the /cost/center/api/cost/stream API with POST. Build the request body per the table above. business_types is hard-coded to 10, query_type to 01, and the time window uses _function expressions to derive the previous full month.
2. Target data source: pick the Kingdee Cloud platform, use batchSave with POST. The real trick here is not field-by-field mapping but the bill-number generation rule — _function concat('FBA补货入库','-',RIGHT(unique_key,12)). The right-12 of the source unique key keeps uniqueness while preserving traceability.
3. Middle-layer field mapping: warehouse / owner uses _findCollection to look up org code by name. This is a common pattern among Qeasy customers: centralized encoding mapping, avoiding hard-coded wids scattered across fields.
4. Nulls and exceptions: origin_accounts on the source can be null, but on the Qeasy side you must decide whether to skip the whole batch or handle field-level nulls. The recommendation is a pre-filter that drops rows with empty origin document numbers.

Implementation steps

We rolled this strategy out in three phases:

• Incremental starting point (first run): pull one full batch for the previous full month as the baseline. The source date window uses _function expressions to auto-derive the first and last day of the previous month, bound directly in the Qeasy source query.
• Full-batch trigger: after the first run completes, manually reconcile bill number, inventory organization, and amount on the Kingdee side. Only after that confirmation should the schedule be opened up.
• Scheduling frequency: the crontab in the source material is 1 1 1 1 1, which is just a placeholder. In practice we recommend running once at the start of each month — the window is strictly limited to "no cross-month", and any cross-month query either returns nothing or drops boundary days. This is a typical "incremental and full-batch dual-track" approach leaning toward full-batch.

Lessons learned

1. Cross-month queries lose data. The source explicitly forbids start_date / end_date crossing a month, so the function must first DATE_SUB to the first day of the previous month, then use LAST_DAY(DATE_SUB(CURDATE(), INTERVAL 1 MONTH)) for the last day. Do not invert the order.
2. Bill-number concatenation must stay stable. In _function concat('FBA补货入库','-',RIGHT(unique_key,12)), do not casually change the RIGHT length. If the historical bill-number rule changes, the idempotency logic on the Kingdee side that keys on bill number will break.
3. Look up org code by name at your own risk. _findCollection find wid from … where name={{wh_name}} looks safe, but if Kingdee renames an org the whole chain breaks. The safer approach is to maintain org wids in Qeasy's "encoding mapping" table and use names only for display.
4. Filter empty origin document numbers early. In the FBA replenishment inbound scenario, records without origin_accounts do appear occasionally. If they flow through, the target FBillNo becomes FBA补货入库-, which trips Kingdee's duplicate check. Add a filter right after the source query in Qeasy to drop rows where unique_key is empty.
5. Do not treat a sync strategy as a transaction. FBA cost streams only stabilize at month-end. Running at the start of the month means late-arriving corrections haven't flowed back yet, and the target transfer-in documents will already have been generated with mismatched amounts. The business rule is "run last month at the start of this month"; on the Qeasy side, just pin the schedule to the start of the month and don't try to build complex compensations inside the platform.

Where it fits and where it doesn't

Fits: cross-border sellers where FBA replenishment inbound goes through Amazon logistics, and the cost stream sliced by Amazon action date in Lingxing needs to land in Kingdee for financial accounting, settled monthly. Does not fit: other business types such as FBA sales outbound, stocktake, or small-balance adjustments — their document shape, cost basis, and bill-number rules are all different and need their own strategies. It also does not fit scenarios that require real-time FBA in-transit inventory; this strategy is a monthly batch process, not a real-time sync.