Integration Overview: OKKICRM to Chanjet T+ — Master Data, Sales Orders, and Log Maintenance

Scenario and Value

In a real engagement, an automotive retail enterprise kept its sales process in OKKICRM and its finance/supply-chain accounting in Chanjet T+/Haoyecai across two ledgers (one per business organization). The pain point was not single-point data entry but a broken closed loop: orders signed in CRM had to be re-entered manually in ERP, master-data changes drifted between the two systems, and discrepancies only surfaced days after a sales peak.

The goal of this integration is straightforward: automatically move customers, products, and sales orders from CRM into the matching ledger in ERP, plus a queue/log cleanup strategy, so that master data and transactional documents stay aligned across both systems. The whole design runs on a private-deployment environment, consists of five integration strategies, and is orchestrated end-to-end by the Qeasy iPaaS platform.

Integration Architecture and Data Flow

The architecture is unidirectional: CRM is the master, ERP is the receiver, and the integration platform handles extraction, transformation, writing, and retries.

┌─────────────────┐                  ┌──────────────────────────┐
│ OKKICRM         │   ── sync ──▶    │ Chanjet T+ / Haoyecai    │
│ (CRM)           │                  │ (ERP, two ledgers)       │
└─────────────────┘                  └──────────────────────────┘
        ▲                                      ▲
        │  pull / write                        │
        │                                      │
        └────────── Qeasy iPaaS ────────────────┘
              orchestration / mapping / scheduling / retry

The data flow has three stages:

• Stage 1 (parallel): Customer → business partner; Product → inventory, written to Ledger A and Ledger B respectively. The three strategies have no mutual dependencies and run concurrently.
• Stage 2 (depends on Stage 1): Sales order → sales order, with line items, depends on customer and product codes already in ERP.
• System maintenance (independent): Delete queue and log records older than 10 days, runs at night, does not compete with business traffic.

Interface List

Implementation Highlights

Staged scheduling. The three Stage-1 strategies are independent and run in the same scheduling window; Stage 2 fires only after Stage 1 lands, so that the customer/material on the order can be resolved in ERP. Although both S2 and S3 are product syncs, their target ledgers differ, so they must be offset (here, at minutes 5 and 10 of every hour) to avoid locking on the target side.

Incremental fields with full-coverage fallback. Customers and sales orders use start_time/end_time or update_time as the incremental window; products use update_time. The initial go-live and data-repair runs are full-coverage jobs scheduled in the 2:00–4:00 AM low-peak window. Incremental is the daily mode, full-coverage is triggered manually on demand, and the two are never mixed.

Centralized code mapping. All three mapping relations live in Qeasy's mapping table: serial_id ↔ Partner Code (CUSTOMER), product_no ↔ Inventory Code (MATERIAL, scoped by target_org), and unit ↔ BaseUnitCode (UNIT). This is the most common pitfall — once mapping logic is scattered across strategy scripts, adding a new ledger or unit becomes a maintenance nightmare.

Idempotent writes. Before writing any master-data or order record, the platform queries by target Code/order number, updates if it exists, creates otherwise. This guarantees no duplicates even when incremental windows overlap or jobs are re-run.

Exception handling and retry. Network/API timeouts use exponential backoff at 30s / 60s / 120s, up to 3 attempts. A single target-side failure does not block the rest of the batch; failures land in sync_failed_records together with source snapshots and error codes, and can be re-run manually. Primary-key conflicts take the update branch directly; missing customer/material mappings raise an alert and the business decides whether to fill the mapping or apply a default value.

Privacy. The design itself does not contain real customer names, phone numbers, or addresses at field level. Credentials and connection strings are stored in environment variables or a secret-management service; ledger identifiers are injected as business parameters at runtime.

Best Practices and Pitfalls

1. Centralize code mappings; do not scatter them in scripts. We have seen cases where the unit mapping was hard-coded inside one strategy's transform function and copied into another. When a new ledger was added, one copy was updated and the other forgotten, leaving every order on that ledger with an empty unit. After consolidating into a single mapping table, adding a new ledger is just a new row keyed by target_org.
2. Write header and lines in separate steps. For order documents with line items, the safe pattern is to confirm the header's customer exists first, then resolve each line's material mapping. Bundling header and lines into a single write call means that one missing material rolls back the whole document, and root-causing becomes painful.
3. Always offset multi-ledger product syncs. When the same product master feeds two ledgers and the jobs run truly in parallel, the target ERP's API layer tends to throw intermittent 5xx under concurrency. A 5–10 minute Cron offset is the cheapest mitigation, and Qeasy's scheduler supports it natively.
4. A dead-letter table is more reliable than email alerts. Instant alerts fire when a single strategy fails ≥3 times in a row, and a daily digest fires when daily failure rate exceeds 5%, but what really saves you is the sync_failed_records dead-letter table — re-runs, data fixes, and reconciliation all depend on it.
5. Treat log cleanup as its own strategy. Tucking queue/log cleanup into a business strategy to save a schedule slot actually slows the main flow when traffic is heavy. A standalone strategy that runs at night and deletes in batches is the most stable posture.

When to Use Qeasy

When an enterprise needs to sync master data and transactional documents across multiple CRM/ERP systems — especially when the target system spans multiple ledgers or organizations — the Qeasy iPaaS platform fits as the unified orchestration layer. It turns field mapping, staged scheduling, idempotent writes, retry handling, and dead-letter re-runs into visual strategies. Adding a new ledger is as simple as cloning an existing strategy and updating the target_org parameter, keeping both implementation and operations costs under control.