Syncing Outbound Records from Jijia ERP to Kingdee Cloud Skyland Other-Outbound Orders: A Single-Strategy Tutorial
What This Strategy Solves
In a real retail supply-chain project we worked on, warehouse operations ran on Jijia ERP while finance and inventory accounting lived in Kingdee Cloud Skyland. Manual double-entry of outbound data not only burned hours every day, it also led to a familiar pain: the two systems' stock numbers drifted apart, and month-end stocktakes broke. This strategy takes Jijia's outbound records, splits them by business type, and auto-generates Kingdee's standard Other-Outbound, Asset-Outbound, VMI-Outbound, Expense-Material-Outbound, and Inventory-Adjustment orders so both ends stay in sync.
Data Flow and Field Mapping
The pipeline is one-way: Jijia ERP (source) → Qeasy Data Integration Platform (middleware for cleansing, mapping, and type dispatch) → Kingdee Cloud Skyland (target, written via batchSave).
The source calls /purchase/inventory/storageInbound/page (a WebAPI). Key parameters: type=Out to filter outbound only, code for precise incremental pulls by document number, and opType / warehouseIds to filter by business type and warehouse.
The target writes through batchSave. Key field mapping:
| Business Meaning | Jijia Source Field | Qeasy Middle Layer | Kingdee Target Field |
|---|---|---|---|
| Document number | code | Pass-through | FBillNo |
| Business type | opType | Mapping dictionary → Kingdee doc type | FBillTypeID |
| Inventory org | warehouseId | {{arrivalWarehouseId}} placeholder | FStockOrgId |
| Pick org | warehouseId | Same variable reused | FPickOrgId |
| Department | Business dept field | Static fallback value | FDEPTID |
| Lines: item & qty | Detail rows | Array flattened into rows | FEntity details |
The business-type mapping is the heart of this strategy: Jijia's opType is translated through a centralized dictionary into QTCKD01_SYS (standard Other-Outbound), QTCKD02_SYS (Asset-Outbound), QTCKD03_SYS (VMI-Outbound), QTCKD04_SYS (Expense-Material-Outbound), QTCKD05_SYS (Inventory-Adjustment).
How to Configure on Qeasy
On the Qeasy Data Integration Platform, this strategy is configured in three segments: source modeling → transformation flow → target modeling.
Source side: Pick API type = WebAPI, method = POST. In the request body, hardcode type=Out, set pagesize=50, and enable autoFillResponse so Qeasy auto-expands the response into a field table.
Middleware layer: Use Qeasy's field-mapping and script nodes to do three things — determine the document type from opType, write the warehouse ID into the {{arrivalWarehouseId}} placeholder, and split header from lines. A common pattern we use at customer sites is centralized code mapping: all opType → FBillTypeID translations live in one independent dictionary table, so adding a new type later only touches the table, not the main flow.
Target side: Choose batchSave, turn on buildModel (Qeasy builds the model from the response), and set idCheck=true to prevent duplicate submission. Headers and lines are split in the middleware layer into two writes: submit the header first to obtain the FID, then backfill the lines so each row hangs under the correct document.
Implementation Steps
We recommend a three-phase rollout:
- Incremental start: Tighten the source API filters to a subset of "last 24 hours + clear business type" to avoid being overwhelmed by historical dirty data on day one. Source cron:
9 20-23,0-9 * * *, covering the night-shift to morning-shift window. - Full pull trigger: After 3 stable days of incremental, run a one-shot script to backfill history, then stop it immediately to avoid racing with incremental.
- Stable scheduling: Target cron:
50 4-9 * * *, offset by 50 minutes from the source to give Kingdee write margin. A safe approach is dual-track incremental + full: daily incremental keyed oncode, plus a monthly full reconciliation pull.
Pitfalls Recap
- Skipping type dispatch and writing everything as one type: On first go-live we wrote all outbound records as
QTCKD01_SYS, so asset and adjustment outflows all took the standard channel and Kingdee's accounts went sideways. After switching to a dictionary mapping, business types are split correctly in the middleware. - Submitting header and lines together caused silent row loss: When
batchSavewrites header and lines in one shot, an empty lines array can be silently dropped. The safe pattern is to create the header first (even with empty lines), then patch lines in a second pass. {{arrivalWarehouseId}}placeholder not fully resolved: When variable resolution fails, Kingdee gets empty values and errors out. Configure a fallback in Qeasy: any unresolved placeholder aborts the whole batch.- Source
codededuplication missed: When one outbound document is modified twice on the Jijia side, Qeasy pulls it twice. Add an in-memory dedup bycodein the middleware. - Department hardcoded as static value: In this case
FDEPTIDuses a static fallback because the Jijia department master data is not yet wired through. The proper fix is to dynamic-map it from Jijia department master data — otherwise every business-line change requires a config edit.
When to Use and When Not to Use
Use when: Source is Jijia ERP, target is Kingdee Cloud Skyland, and you need to post outbound records by business type into different document types — typical for retail or trading companies aiming to eliminate manual re-entry and reconcile both ends daily. Do not use when: Jijia's business types are still unstable and frequently added; or when Kingdee needs project-based accounting rather than document-type accounting. In the latter case, switch to a project-auxiliary-accounting design instead.