Practical Guide to Synchronizing WDT Sales Outbound Orders (Jingcai-Related) to Kingdee Cloud Galaxy
What This Strategy Solves
In one retail operation, an e-commerce system and a financial supply-chain system are used together. After order fulfillment, the e-commerce system generates a sales outbound document, while Kingdee Cloud Galaxy must record the corresponding outbound transaction. The task may look like simple document transfer, but production issues often arise when the Jingcai relationship identifier, warehouse, material, batch, and quantity definitions differ. Missing documents, duplicate postings, and broken traceability are common consequences. We use the lightweight data integration platform to handle this flow, with Qeasy supporting the implementation. The goal is not merely to send a document; it is to establish a stable and traceable outbound synchronization mechanism.
Data Flow and Field Mapping (Source → Middleware → Target)
The flow is: WDT sales outbound order → the lightweight data integration platform middleware layer → Kingdee Cloud Galaxy sales outbound order. The middleware layer is responsible for reading, standardization, relationship validation, failure recording, and retries. It does not change the semantic meaning of the source document.
| Business meaning | Source field | Target field | Configuration focus |
|---|---|---|---|
| Document identity | Outbound order number | Document number | Preserve uniqueness and prevent duplicate synchronization |
| Business relationship | Jingcai relationship information | Source or relationship field | Retain the original relationship number for idempotency and traceability |
| Outbound date | Outbound time | Outbound date | Define the time zone and date format |
| Warehouse | Warehouse code | Inventory organization and warehouse | Manage mappings centrally |
| Product | Product code/specification | Material code | Do not assume master-data codes match automatically |
| Quantity | Outbound quantity | Base quantity | Validate the unit and quantity precision |
| Batch | Batch information | Batch field | Pass batch data at line level when applicable |
| Source tracking | Source document information | Source document number | Support reconciliation and issue tracing |
A typical approach is to manage code mappings centrally instead of making temporary decisions inside each document. The lightweight data integration platform allows these rules to be maintained in one place, reducing the impact of later material or warehouse mapping changes.
How to Configure It on the Lightweight Data Integration Platform
First, create the source and target connections and define the scope for reading sales outbound headers and lines. The source query should include at least the outbound order number, Jingcai relationship information, outbound date, warehouse, product, quantity, and any required batch fields.
Second, define document transformation rules. Map the header number, date, warehouse, and source relationship to the target header. Map product code, outbound quantity, unit, and batch to the target lines. We recommend processing the header and lines in separate stages. Validate and persist the header in the middleware first, then convert each line and associate it with the header. If one line fails, the entire outbound document is not discarded.
Third, define the target-document creation rules. The Kingdee side generally needs the source relationship information to determine whether the corresponding document already exists. If it already exists, the flow should update or skip it rather than create another document. Missing key fields, unresolved code mappings, invalid dates, or abnormal quantities should be recorded as exceptions and trigger an alert.
Fourth, configure write-back and logging. At minimum, retain the source order number, target document number, processing status, failure reason, and processing time. Qeasy can make the failure reason available in queryable run records, allowing the business team to trace a document instead of seeing only a failed job.
Implementation Steps (Incremental Start / Full Trigger / Schedule)
Before implementation, define a clear incremental start point and record the outbound documents created after that point. After the start point, the scheduled job reads newly created or changed outbound documents at the agreed frequency. During the first launch, use a short observation period, confirm that incremental data is complete, and then select a production frequency that matches business timeliness and interface capacity. The exact frequency should be based on the actual environment.
Before incremental synchronization, validate Jingcai relationship information and master-data code mappings. After the header passes validation, process the line details. If a target document already exists based on the source relationship, mark the source as processed. Consider the execution complete only after the target document is created successfully. Failed documents remain in a retry queue and are handled by error type; the system should not create a new source relationship automatically.
Full synchronization is intended for historical backfill or reconciliation before launch, and should not run unconditionally alongside high-frequency incremental jobs without controls. A safe pattern is a dual-track approach: incremental synchronization for daily operation and full synchronization as a separate job with an explicit time window and a defined update policy. Validate the full job on a small scope before expanding it, and enable duplicate checks to prevent historical documents from being written again.
After launch, split the schedule into observable stages: read, transform, write, and write back results. Record quantities and error details for every stage. Network issues, interface throttling, or temporary business-validation failures can follow the platform’s retry policy. Deterministic errors such as missing codes or invalid date formats should be routed to manual handling rather than retried indefinitely.
Lessons from the Field
- Using only the document number for uniqueness is risky. One source business may produce multiple outbound documents or line details. Retain Jingcai relationship information and combine it with target-document status to decide whether to create, skip, or update.
- Assuming master-data codes match directly is a typical mistake. Product code rules may differ between systems, and matching by name is not reliable. Establish centrally managed code mappings in the lightweight data integration platform, and maintain changes in one place.
- Whole-document failure can discard valid lines. A common failure is to drop the entire document when the header succeeds but one line fails. Process header and lines separately; persist the header first and block only the affected line.
- A full job can damage already processed data. Full synchronization is not the same as creating every document again. Add source-relationship idempotency checks and define whether historical records may be updated. When full and incremental jobs run together, specify whether they may execute simultaneously.
- Binary success/failure logs are insufficient. Without the source order number, target document number, failed stage, and error reason, troubleshooting is difficult. When Qeasy handles the flow, preserve stage-level logs and convert failures into retryable or manually actionable states.
Suitable and Unsuitable Scenarios
This strategy suits public-cloud integrations where sales outbound documents generated by an e-commerce system must become the basis for sales outbound records in a financial supply-chain system, while preserving Jingcai relationships. It requires resolvable code mappings, confirmed interface permissions, defined target-document rules, and available master data. It should not be copied directly when the source has no stable relationship information, the target system does not allow automatic sales-outbound creation, or the business requires real-time confirmation for every order. In those cases, use an interface confirmation flow, manual handling, or synchronize an intermediate document for review first.