Offline Sales Outbound Sync: A Practical Configuration Guide from Jushuitan to Kingdee Cosmic

What This Strategy Solves

For a multi-channel retail business, offline sales outbound orders generated at store counters need to flow into Kingdee Cosmic for inventory deduction and financial accounting. Once Jushuitan has approved an outbound order but Kingdee has not received it, the two inventory views drift apart by end of day. This strategy aims to push offline outbound orders into King's local warehouse in a stable, well-defined manner, supporting both historical backfill and incremental sync side by side.

Data Flow and Field Mapping

The pipeline is unidirectional: Source system (Jushuitan) → Qeasy integration middleware → Target system (Kingdee Cosmic, local warehouse). The middleware does not perform business calculations; it only handles mapping, rewriting, default value filling, and failure re-submission.

Key field mapping (excerpt; actual fields follow the customer's master data):

Two details must be agreed up front. First, the store-to-local warehouse mapping rules should be centrally maintained in Qeasy, not scattered across scripts. Second, the tax-inclusive unit price may be split into tax-exclusive and tax-inclusive columns on the Kingdee side, so the rewriting logic should be phased: pass-through first, refinement later.

How to Configure It on Qeasy

This is how we usually implement it on the customer's site:

1. Create the source connection: point to Jushuitan's outbound query interface, only fetch approved offline sales outbound orders, and put filter conditions in the request parameters—do not fetch everything and filter downstream.
2. Create the target connection: use Kingdee Cosmic's save/audit interface, isolated by local warehouse organization.
3. Configure field mappings: in Qeasy's visual mapping canvas, map fields one by one. Handle tax-inclusive prices in a single price-rewriter so the logic is auditable.
4. Configure error handling: retry three times on failure; entries that still fail go to an exception pool for manual resubmission, never re-enter the auto loop.
5. Enable logs and monitoring: keep row-level logs for at least seven days so issues can be replayed.

Centralized management of code mappings is the biggest advantage of a platform like Qeasy over hand-written scripts. When the customer later adds new stores or warehouses, only one mapping entry needs to change, not the main sync flow.

Implementation Steps

We recommend going live in the order of "stabilize incremental first, then backfill in full":

• Phase 1 · Incremental start point: on the night of go-live, do not run history yet. Only pull newly approved orders after go-live, every 15 minutes, for three business days, and confirm zero discrepancies. The goal of this phase is to verify the correctness of mapping and field rewriting.
• Phase 2 · Full backfill: once the incremental run is stable, backfill history in date-range batches of 200–500 orders per batch. After each batch, reconcile inventory balance and document list to confirm no duplicates and no missing entries.
• Phase 3 · Routine scheduling: after full backfill, switch to daily scheduling—incremental every 15 minutes during the day, and one full reconciliation at night (compare both sides without writing back).
• Phase 4 · Monitoring and alerting: three metrics go into the alert dashboard—inventory variance threshold, failed document count, and interface latency.

Pitfalls from the Field

• Pitfall 1: Mixing "approved" with "shipped". In Jushuitan, "approved" does not equal "shipped". Filtering by shipping status alone will miss orders. A safer approach is to filter by both approved status and non-empty logistics tracking number.
• Pitfall 2: Warehouse mapping scattered across scripts. The more stores there are, the more scripts there are to maintain, and root-causing errors becomes very slow. Most customers eventually centralize these mappings in Qeasy's mapping tables.
• Pitfall 3: Inconsistent price and tax conventions. Jushuitan defaults to tax-inclusive prices, while Kingdee defaults to tax-exclusive. Direct pass-through causes amount mismatches. A safer approach is to run the price field alone for a week, confirm the rewriting logic is correct, then enable the remaining fields.
• Pitfall 4: Full backfill and incremental running together cause duplicates. If the incremental window is open during historical backfill, the same order may be pushed twice. Either temporarily close the incremental window during backfill, or add a dedup gate keyed on document number.
• Pitfall 5: Reconciliation only by total amount. Matching totals does not mean matching line items. Reconciliation must be done at SKU-level quantity—this is the most common pitfall on customer sites.

When to Use It and When Not To

Use when: multi-channel retail, stores and warehouses are separated, document volume is stable enough for incremental push, and the business needs inventory and financial closure in the ERP. Do not use when: real-time latency is required at the minute level, multi-book multi-organization scenarios, complex split/merge order rules, or zero tolerance for failure with no acceptance of manual remediation. In the latter cases, evaluate a direct system-to-system connection first.