Guanyi Cloud to Kingdee YXC Supply Chain Integration: 8-Strategy Workflow and Code Mapping Design

Scenario and Value

E-commerce businesses typically adopt a dual-system architecture combining an e-commerce ERP with a financial ERP: the e-commerce ERP handles products, stores, orders, and fulfillment, while the financial ERP owns materials, customers, warehouses, inventory, and accounting. Because the master data models, document coding, and state machines differ across the two systems, missing cross-system code mappings or poor synchronization orchestration often leads to phantom inventory, duplicate sales orders, and reconciliation difficulties.

Based on the supply chain integration scenario of a retail enterprise, this article presents a complete workflow of eight integration strategies between the e-commerce ERP (Guanyi Cloud) and the financial ERP (Kingdee YXC V2). The workflow covers four phases—master data queries, master data synchronization, business document synchronization, and inventory synchronization—and addresses the following problems:

• Sequencing and dependency management between master data and business document strategies;
• Cross-system code mapping mechanisms (material, customer, warehouse, store);
• Selection of incremental timestamps and maintenance of time variables;
• Tiered handling of exceptions, retries, and dead-letter queues.

The solution applies to any iPaaS / ETL / data synchronization platform and is not tied to a specific vendor.

Integration Architecture and Data Flow

The overall architecture has three layers: the e-commerce ERP serves as the business source, the financial ERP acts as the accounting and inventory backbone, and the integration platform functions as the middle layer responsible for data transformation, code mapping, scheduling orchestration, and queue maintenance.

flowchart TB
    subgraph EC["E-commerce ERP"]
        A1[Products]
        A2[Stores]
        A3[Delivery Orders]
        A4[Return Orders]
        A5[Stocktaking Orders]
        A6[Sales Orders]
    end

    subgraph FE["Financial ERP"]
        B1[Materials]
        B2[Customers]
        B3[Warehouses]
        B4[Material List]
        B5[Sales Delivery Notes]
        B6[Sales Return Notes]
        B7[Sales Orders]
        B8[Real-time Inventory]
    end

    subgraph PLAT["Integration Platform"]
        C1[Code Mapping]
        C2[Cross-scenario Lookup]
    end

    A1 -->|Strategy 1| B1
    A2 -->|Strategy 2| B2
    B3 -->|Strategy 3| C2
    B4 -->|Strategy 4| C2
    A3 -->|Strategy 5| B5
    A4 -->|Strategy 6| B6
    B7 -->|Strategy 7| A6
    B8 -->|Strategy 8| A5

Strategies are executed in four dependent phases. Phase 1 pulls warehouse and material lists from the financial ERP (QUERY type, platform-only). Phase 2 writes master data (materials, store-customer) into the financial ERP. Phase 3 synchronizes sales delivery notes, sales returns, and sales orders. Phase 4 reflects real-time inventory from the financial ERP as stocktaking orders back in the e-commerce ERP.

Interface List

Implementation Points

Code Mapping Dependencies

All business document strategies depend on code mapping tables that must be configured before deployment or auto-populated through master data synchronization:

Scheduling and Parallelism

Within Phase 1, strategies 3 and 4 can run in parallel; within Phase 2, strategies 1 and 2 can run in parallel; within Phase 3, strategies 5, 6, and 7 can run in parallel. Phase 2 depends on Phase 1; Phase 3 depends on Phase 2; Phase 4 depends on material and warehouse mappings from Phase 2. Source-side and target-side strategies should be staggered to avoid simultaneous reads and writes competing for resources.

Incremental and Full Synchronization

Full synchronization should run during initial deployment or data repair, ideally outside business peak hours. Daily runs should be incremental. Time field selection depends on the source API capabilities: materials and stores use modify_date / modify_start_date / modify_end_date; sales delivery uses start_delivery_date / end_delivery_date; sales returns use in_begin_time / in_end_time; sales orders and real-time inventory use modify_start_time / modify_end_time. Maintaining LAST_SYNC_TIME and CURRENT_TIME variables to advance the incremental window is recommended.

Best Practices

Monitoring and Alert Thresholds

Retry Strategy

• Network timeout: exponential backoff, up to 3 retries (30s / 60s / 120s);
• Target system 5xx: 3 retries at 30s / 60s / 120s intervals;
• Missing code mapping: no retry, log and skip;
• Business validation failure (e.g., duplicate document number): no retry, write to dead-letter queue;
• Token expiration: trigger connector refresh, then retry once immediately.

Staggering and Scaling

Master data queries run at high frequency (3–10 minutes). Use a shared connector and connection pool on the platform side to avoid repeated connection setup. Inventory synchronization writing back as stocktaking orders is a heavy operation—run every 30–60 minutes and only sync warehouse dimensions that have changed. During promotional events on the e-commerce side or month-end closing on the financial side, temporarily lower the frequency of non-critical strategies and lock full-load jobs.