Delivery Order to Sales Outbound Sync Tutorial: Guanyi Cloud to Kingdee Cloud Cosmic
What This Strategy Solves
In a retail scenario where the front-end runs e-commerce on Guanyi Cloud and the back-end runs finance and inventory on Kingdee Cloud Cosmic, a common pain point emerges: delivery orders have already deducted inventory on the e-commerce side, but no corresponding sales outbound order exists in the ERP, causing the inventory ledger and financial ledger to drift over time.
This strategy synchronizes the delivery order into Kingdee Cloud Cosmic as a sales outbound order, anchoring inventory and receivables to the correct accounting entity. On the customer site we use the Qeasy data integration platform to carry this link. The goal is to align document, inventory, and amount dimensions in the middle layer so the back-end only needs to receive and reconcile.
Data Flow and Field Mapping
The overall flow is A_TO_B: the source pulls delivery orders from Guanyi Cloud · Qimen, the middle layer performs cleansing and mapping, and the target writes sales outbound orders into Kingdee Cloud Cosmic.
Key field mapping (typical dimensions; actual values follow the customer's master data):
| Business Meaning | Guanyi Cloud · Qimen (Source) | Middle Layer | Kingdee Cloud Cosmic (Target) |
|---|---|---|---|
| Document number | Delivery order no. | Pass-through | Document number (FBillNo) |
| Document date | Delivery date | YYYY-MM-DD normalized | Business date |
| Customer code | Store / member code | Via customer master mapping | Customer code |
| Material code | Merchant code / SKU | Via material mapping table | Material code |
| Warehouse | Warehouse code | Via warehouse mapping table | Receiving warehouse |
| Quantity | Outbound quantity | After UoM conversion | Actual quantity |
| Unit price & amount | Order line amount | Tax-inclusive / exclusive conversion | Amount, price-tax total |
Two dimensions are recommended to be fixed in the middle layer: centralized encoding mapping management (independent mapping tables for customer, material, and warehouse, which Qeasy supports natively) and header-body phased processing (write the header first, then batch the body to avoid large transactions that cause target-side rollback).
How to Configure on Qeasy
On the Qeasy data integration platform we usually structure it as follows:
- Data source registration: Connect to the Guanyi Cloud · Qimen side, select the delivery order-related interfaces; connect to Kingdee Cloud Cosmic and prepare the credentials required for the target document (account, secret, etc. are configured per the customer's actual environment and are not shown here).
- Strategy orchestration: Create a new strategy. The naming convention "source_system_target_system_business_object" is recommended so it can be located at a glance in the strategy list.
- Field mapping configuration: In the Qeasy mapping canvas, configure source-middle-target correspondence for each field. When customer, material, or warehouse encoding conversion is required, hook up the corresponding mapping table component directly.
- Conversion scripts: Perform lightweight conversions on dates, amounts, and tax-inclusion logic to avoid embedding business rules into the target.
- Target write: Configure the sales outbound order save interface of Kingdee Cloud Cosmic, choosing single-document or batch write based on downstream performance.
- Exception handling: Configure failure retry, skip, and alerting channels. Typical failure causes include missing encoding mapping, insufficient inventory, and empty required fields.
Implementation Steps
We recommend a three-phase rollout rather than running a full sync immediately:
- Incremental starting point: Begin with "by document modification time increment", schedule it to pull incremental data at fixed intervals. This validates mapping and document-creation logic first. This step can use Qeasy's scheduled task, with frequency set to a business off-peak period, e.g., every 15 to 30 minutes.
- Full trigger: Once the incremental flow is stable, perform a one-shot historical full backfill. The full process should be batched, for example slicing by document date by month, to avoid oversized single transactions.
- Schedule frequency: After entering the steady state, switch to daily incremental scheduling and set the timer according to the business rhythm. For stores with high real-time requirements, the interval can be shortened or switched to event-triggered mode.
This is the commonly used "incremental and full dual-track" approach: incremental keeps freshness, full keeps historical integrity, and the two are scheduled independently without interfering with each other.
Pitfall Retrospective
- Encoding mapping not centralized: The first version hard-coded customer encoding in the conversion script; three months later the customer updated their archive in the ERP and the two sides no longer matched. The reliable approach is to place customer, material, and warehouse mapping tables in Qeasy's centralized maintenance module, so a change on the source side is sensed on the target side.
- Header and body submitted in one transaction: When a delivery order has many body lines, a single submission easily triggers target-side timeout and rollback. It is recommended to write the header first, then submit the body in batches, and configure the batch size and retry strategy in Qeasy.
- Inconsistent amount dimensions: The source side is tax-exclusive while the target is tax-inclusive; missing tax calculation in the middle causes even a one-cent mismatch that finance will catch. A typical mistake is mapping only the amount field without carrying the tax rate and tax amount.
- Time zone and date format: The source returns timestamps while the target expects YYYY-MM-DD strings; missing time zone handling in the conversion script causes a one-day difference in document date, which then affects the inventory period.
- Duplicate document protection: The Guanyi Cloud side may produce duplicate pushes due to retransmission or network jitter; without deduplication the target side will generate two outbound orders. It is recommended to use document number + line number as an idempotency key in the middle layer, which can be reused directly via Qeasy's idempotency configuration.
Applicable and Non-Applicable Scenarios
Applicable: enterprises whose e-commerce front-end and ERP back-end need aligned inventory and receivables, with daily document volumes ranging from several thousand to tens of thousands, and where the source has a reliable document modification time field. Not applicable: scenarios that require second-level real-time inventory, where the source lacks a reliable incremental field, or where the target is another business system; in those cases an event-driven approach or API direct connection is recommended.