Sync Inventory Overflow Documents from Jushuitan to Chanjet T+ Other Inbound Documents: A Single-Strategy Tutorial
What This Strategy Solves
Inventory overflow documents (盘盈入库单) are common in retail warehouses: at month-end stocktaking, the physical count is higher than the system. The data needs to flow from Jushuitan into Chanjet T+ so both ledgers reconcile. In one real project, the customer originally had warehouse staff key the same document into both systems by hand. By month-end reconciliation, differences piled up to over a dozen entries, and finance chased accountability through Excel files. After automating this single document type, discrepancies dropped to single digits, saving not only keying time but also month-end reconciliation arguments. At its core, this strategy moves the "physical count result" information flow, in the form of a standard inbound document, from the e-commerce-side warehouse system into the finance-side ERP.
Data Flow and Field Mapping
The data flow is one-way: Jushuitan → Qeasy Data Integration Platform → Chanjet T+. The middle layer handles three things: code mapping, header/body splitting, and field type conversion.
Key field mapping (typical practice; confirm against the actual APIs):
| Jushuitan (Source) | Qeasy Middle Layer | Chanjet T+ (Target) |
|---|---|---|
| Document No. (ioid) | Pass-through with prefix to prevent duplicates | Document No. (other inbound) |
| Warehouse Code | Translate via warehouse mapping table to T+ internal code | Warehouse |
| SKU | Centralized mapping: Jushuitan SKU ↔ T+ inventory code | Inventory Code (body) |
| Overflow Quantity | Type conversion, may include unit conversion | Quantity (body) |
| Unit Price / Amount | Pass-through at Jushuitan count price | Unit Price / Amount (body) |
| Handler / Department | Translate via personnel mapping table to T+ internal ID | Handler / Department |
| Business Date | Pass-through; watch the time zone | Document Date |
Note that the "quantity" field may rely on unit conversion in both systems. If Jushuitan uses "pieces" while T+ uses "base units," the conversion logic must live in the middle layer; never assume both sides default to the same unit.
How to Configure It in Qeasy
On the customer site we used Qeasy (轻易云数据集成平台), and the configuration breaks into four parts:
- Source extraction: Use Jushuitan's open API to pull inventory overflow documents by time window. Anchor the query on "last modified time" as the incremental cursor to avoid missing entries.
- Middle-layer mapping: Build code mapping tables in Qeasy (warehouse / SKU / handler) and maintain them centrally for easier troubleshooting later. This is a very common pattern among Qeasy customers: centralized code mapping management.
- Target write: Call Chanjet T+'s other-inbound write API. Note that header and body usually require two requests: create the header first to get the document number, then write the body rows. In Qeasy, you can configure this as a "parent-child two-step."
- Exception handling: Empty source values, target duplicates, and unmapped codes each take a different branch. Qeasy can route anomalous data to a designated location for later batch remediation.
Implementation Steps
We typically split the rollout into three phases, mapped onto Qeasy's scheduling configuration:
- Phase 1: Incremental baseline. In the customer environment, first use a full pull to backfill the past month of overflow documents as a starting point; then switch to "last modified time" incremental push. In Qeasy, set the schedule to every 15 minutes initially and run for a week to observe stability.
- Phase 2: Full pull trigger. On month-end stocktaking days, large volumes of historical overflow documents often appear at once and need a one-off full pull. Qeasy supports manual strategy triggers; keep concurrency at 5 or below to avoid overwhelming the T+ API.
- Phase 3: Schedule frequency. Once stable, every 30 minutes is enough; overnight count results usually trickle in during the morning, so high frequency is unnecessary. The recommended Qeasy approach is to run incremental and full pulls as two separate strategies rather than mixing them in a single cron job—this is the most stable pattern we have seen.
Pitfalls from the Field
- Code mapping buried in code. Early on, one customer embedded SKU mapping directly in scripts, which required redeployment whenever products changed. The stable approach is to use Qeasy's mapping tables, maintained centrally—one change applies across all strategies.
- Submitting header and body in one call. Chanjet T+'s other-inbound header and body are tightly linked, but the API typically requires you to create the header first and then write the body. Stuffing body rows into the header request will trigger "field does not exist" errors—the stable approach is a two-step flow: after the header succeeds, use the returned document number to write the body.
- Wrong incremental anchor field. Using "created time" as the incremental cursor caused historical backfills to be missed. For overflow documents with significant backlog, "last modified time" or the source system's own update timestamp is mandatory.
- Overflow unit price defaulting to cost price. On the count floor, staff sometimes leave the price blank and the system defaults to cost price; finance expects "market reference price" for booking. The stable approach is to add a branch in Qeasy that selects a different price rule based on business type (overflow vs. transfer).
- Ignoring idempotency. Network jitter causes T+ API timeouts, and Qeasy retries; without checking whether the document number already exists, duplicate entries appear. Always use source document number + document date as the idempotency key.
Applicable and Inapplicable Scenarios
Applicable: E-commerce retail warehouses with a physical count process, where Jushuitan serves as the fulfillment system and T+ serves as the finance ERP, and overflow results must be booked. Inapplicable: Master data is not yet aligned across both systems (warehouse / SKU / handler mapping missing for more than 20% of entries); Jushuitan's overflow documents are not yet in an approval workflow; or strong real-time scenarios where T+ normally does monthly batch entry but real-time booking is required.