Practical Tutorial: Syncing Distributors from Jushuitan to Chanjet T+ Partner Units
What This Strategy Solves
In a multi-channel distribution business, a retail enterprise runs Jushuitan for online shops and distributors, and Chanjet T+ for accounting. The classic pain point is: distributors are first created in Jushuitan and generate transactions there, but the finance side cannot see these partner units, so reconciliation is done manually offline, and three months later the numbers on both sides simply do not match.
We use the Qeasy data integration platform to build a one-way sync strategy that treats Jushuitan's distributor/shop data as the master data source and pushes it into Chanjet T+'s partner unit archive. This gives ERP-side invoicing, reconciliation, and accounts receivable a unified "customer master" to rely on.
Data Flow and Field Mapping
The overall direction is B_TO_A: Jushuitan (source) → Qeasy middleware layer (mapping, cleansing, deduplication) → Chanjet T+ (target). We adopt the "centralized encoding mapping" pattern common among Qeasy customers, keeping encoding conversion rules in a dedicated mapping table in the platform so future changes happen in one place.
| Business meaning | Jushuitan side (source) | Middleware handling | Chanjet T+ side (target) |
|---|---|---|---|
| Unit code | Shop/distributor code | Prefix + truncation | Partner unit code |
| Unit name | Shop/distributor name | Trim spaces, unify full-width | Unit name |
| Contact | Contact person | Pick primary contact | Contact |
| Phone | Phone | Validate mobile format | Phone |
| Address | Province/city/district + detail | Concatenate to one line | Address |
| Active status | Enabled/Disabled | 0/1 conversion | Is disabled |
The incremental key is "unit code + last modified time", which identifies both new entries and updates to existing distributors.
How to Configure in Qeasy
In the Qeasy data integration platform, create a new B_TO_A sync strategy. The source connector points to Jushuitan's shop/distributor API, and the target connector points to Chanjet T+'s partner unit write API. Key configuration points to brief the onsite team:
- Source extraction: Enable "incremental by last modified time". After the initial full sync, only changed rows are pulled, avoiding daily full loads.
- Middleware mapping: Put the field mapping table into Qeasy's "Mapping Configuration" module. Keep encoding mappings in a separate dimension table so future prefix changes do not touch the main flow.
- Deduplication and fallback: In Qeasy's cleansing step, deduplicate by "unit code". Drop rows with empty codes so they never reach the target.
- Target write strategy: Use upsert by code (update if exists, insert if not) instead of delete-then-insert, so existing accounts-receivable references in ERP are not broken.
- Retry and alerting: In Qeasy, configure 3 retries with exponential backoff, and push failures to the enterprise IM alerting group.
Implementation Steps
We recommend a phased approach covering "incremental anchor → full trigger → scheduling", which is the most common "dual-track" landing pattern among Qeasy customers.
Phase 1: Align the incremental anchor. Define a clear start time in Jushuitan (for example, a go-live date) and let the "last modified time" field pull from that point. The purpose is to align the accounting periods on both sides and avoid mixing in dirty historical data.
Phase 2: One-time full trigger. After the incremental strategy runs stably for 24 hours, manually trigger a full sync to backfill historical distributors prior to the anchor. Schedule this full sync during a business off-peak window to avoid conflicts with finance closing.
Phase 3: Steady-state scheduling. In normal operations, run the incremental sync every 15 minutes, and run an additional difference check once a day in the early morning to catch missed rows. Qeasy's scheduler supports crontab directly, with no extra servers to deploy.
Pitfalls and Lessons Learned
This strategy looks like a simple "master data sync", but real projects hit plenty of traps.
- Pitfall 1: Using the shop name as the code. Jushuitan shop names change; codes do not. The typical mistake is treating names as primary keys, which causes duplicate distributor records on the ERP side. The safe practice is to use the code as the unique identifier.
- Pitfall 2: Address fields split too finely. The source splits province/city/district, while the target stores the address as a single line. A common miss is taking only the detail line and dropping the region. The safe practice is to concatenate in the middleware layer with a delimiter.
- Pitfall 3: Active status reversed. The source uses "enabled=1, disabled=0"; the target's "is disabled" flag has the opposite meaning. Without conversion, a distributor disabled in the source ends up enabled in ERP, leading to incorrect invoicing.
- Pitfall 4: Same code, different entities. Distributors with the same name in different regions can collide. Encoding prefixes must carry a region dimension. In Qeasy's mapping table we generate ERP codes as "region code + sequence" to avoid collisions.
- Pitfall 5: Discarding rows when contact/phone is empty. Some distributors register only a name, with contact fields empty. The source allows this. The safe practice is to allow contact/phone to be empty while keeping code and name mandatory; do not drop master data because of optional fields.
Where It Applies and Where It Does Not
Applies: multi-channel distribution and e-commerce businesses that need unified partner-unit master data in ERP for reconciliation, invoicing, and AR analysis; distributor master data is maintained by e-commerce/operations, finance only consumes it.
Does not apply: scenarios where distributor onboarding requires approval flow inside ERP, or where the same customer must be maintained bi-directionally. In those cases, use "approval-driven bi-directional sync" instead of one-way push.