From Jushuitan Inventory Count to Xingchen Inventory Profit Sync: A Hands-On Strategy on Qeasy Integration Platform

What This Strategy Solves

In a multi-system landscape of a retail enterprise, stores run daily inventory operations on Jushuitan, while finance and supply chain settle on Kingdee Cloud Xingchen. After a stock count, the source system only generates a "count document" recording variances; the finance side needs an "inventory profit document" with accounting meaning—only when the inventory profit document is posted can the book-to-physical variance reach the general ledger.

The essence of this strategy is to decompose and convert the source system's count document into the target system's inventory profit document according to business rules, while fully transmitting key line-item information such as quantity, batch, warehouse, and variance reason. We use the Qeasy (Qeasy) Data Integration Platform to host the entire chain, preserving the variance facts in the source system while delivering compliant posting vouchers to the target system.

Data Flow and Field Mapping

The chain is one-way push: source system count document → Qeasy integration platform (middleware) → target system inventory profit document.

The middleware is not a simple pass-through; it carries three responsibilities: code mapping, header/body separation, and variance direction determination. The table below shows the desensitized key field mapping:

The middleware uses Qeasy's "Centralized Code Mapping Management" capability to put all warehouse, product, and customer mappings in one configuration table for maintenance. Once the source system's warehouse changes, no code change is needed—only the mapping table. This is one of the most common patterns among Qeasy customers.

How to Configure on Qeasy

On the Qeasy integration platform, this strategy is implemented in three blocks:

1. Source data source: Configure Jushuitan's open API to periodically pull approved count documents, filtering out drafts and voided statuses.
2. Middleware transformation: Use Qeasy's "Dataset" for field cleansing and mapping. We adopt the "Header and Body Phased" design: first extract the header (warehouse, date, counter), then process line items separately; header and body are linked via document number and pushed to the target system as separate payloads.
3. Target system write: Call Kingdee Cloud Xingchen's inventory profit creation API to write the transformed data.

Several configuration points are worth elaborating:

• Incremental and Full Dual-Track: A common Qeasy customer pattern is to use incremental sync in daily operation (based on last-modified timestamp) and full sync during go-live and month-end (date-range backfill). In Qeasy's scheduling, configure these as two independent jobs with different crontabs—incremental every 30 minutes, full sync triggered manually or on a monthly schedule.
• Variance direction determination: The variance quantity in count documents can be positive or negative; only positives generate inventory profit documents. Use a simple if-expression in the middleware to filter out negatives, avoiding mixing inventory losses into inventory profit documents.
• Idempotency: Use the source system document number as the target system's external document number. Duplicate pushes will be deduplicated by target system rules, avoiding duplicate postings.

Implementation Steps

When deploying for the customer, we usually proceed in three steps:

Step 1, confirm the incremental start point. Take one count document sample from each system, reconcile field differences, complete code mapping on Qeasy, and finalize SQL and scripts. The incremental start point is typically the start of the month or count cycle, with historical data backfilled via full sync.

Step 2, trigger full sync. Full backfill is recommended during off-peak hours, such as 2 AM. After the full job completes, manually reconcile in both systems to confirm header and line item quantities, amounts, and warehouses are fully consistent.

Step 3, switch to daily scheduling. Incremental scheduling pulls approved count documents every 30 minutes; after middleware transformation, write to the target system. For the first month, daily reconciliation is recommended; once stable, switch to weekly. The "safe approach" here is: do not aggressively shorten the scheduling interval at first—ensure chain stability first, then pursue timeliness.

Lessons Learned

1. The "approved" status of count documents is not fully reliable. Documents marked "approved" in the source system but with zero line quantity generate empty inventory profit documents in the target system. This is a common pitfall. The safe approach: add a line quantity validation in the middleware, skip empty lines.

2. Batch number garbled characters. Some legacy batch numbers in the source system contain special characters; the target system throws errors directly. A typical mistake is testing only clean data without preparing dirty data. Production environments must replay with historical dirty data.

3. Missing warehouse mapping. After new stores open, the source system adds warehouse codes, but Qeasy's mapping table is not updated in time, causing inventory profit documents to attach to the default warehouse. Once this happens, manual adjustments are required. The safe approach is to make the warehouse mapping table a subscribable configuration, with automatic notifications when new warehouses go live.

4. Incremental missed documents. The source system's timestamp is based on creation time, not last-modified time. Documents rejected and re-approved will be missed if pulling only by creation time. Our approach is to use last-modified time and persist cursors in Qeasy's cursor table.

5. Duplicate inventory profit document pushes. During network jitter, Qeasy's retry mechanism will call the target API repeatedly. The "use document number as idempotency key" approach mentioned earlier must be enforced; otherwise the target system will produce two identical inventory profit documents.

Applicable and Non-Applicable Scenarios

Applicable: Enterprises with multi-system coexistence, where the source system handles business operations and the target system handles financial posting, and where count variances need to be posted separately as inventory profit/loss.

Not applicable: Enterprises running only one system; scenarios where count results directly generate profit/loss documents within the source system without cross-system needs; and enterprises requiring less than 30-minute real-time sync and accepting T+1 reconciliation—the complexity of this chain may outweigh actual benefits.