Authoritative Tutorial on the Field Handbook for Lemeng-to-DingTalk Master Data Sync Interface
What This Interface Solves
In supply chain and OA collaboration scenarios, supplier master data and supplier settlements often live on both the business system side and the approval system side. We need to sync supplier profiles and settlement documents from Lemeng into DingTalk's OA approval and exported document flows, unifying the approval entry point and preserving audit trails, eliminating duplicate manual entry and inconsistent definitions.
Interface Capability Overview
Authentication: The source Lemeng side uses API keys / account credentials; the target DingTalk side uses app AccessToken (obtained via AppKey / AppSecret). All credentials are stored in a secrets management service — never hard-coded in scripts.
Request / Response Structure: Lemeng returns paginated JSON lists (with a body object containing fields like supplier_num, supplier_bank, supplier_bank_account). DingTalk accepts processInstances or OA approval parameters, where the core payload is the form_component_values array, each item being {name, value} mapping to a form control.
Pagination / Incremental Mode: Lemeng supports pagination via page_no and page_size, and incremental windows via date_type (audit time / creation time) plus date_from / date_to. Supplier master data can be synced incrementally via last_edit_time or supplier_num. The platform maintains LAST_SYNC_TIME and rolls it forward after each successful run.
Typical Field Mappings
| Field | Type | Meaning | Field Notes |
|---|---|---|---|
| supplier_settlement_no / supplier_num | string | Settlement No. / Supplier Code | Primary key; fallback needed when empty (e.g. date('Ymd').'00001') |
| supplier_name / supplier_bank_account_name | string | Supplier Name | Lemeng may prioritize bank account holder name — confirm against the actual API |
| settlement_date | date | Settlement Date | Watch for time zones, normalize to business day |
| settlement_total_money | number | Total Settlement Amount | Alternatively settlement_payment_money — prefer the total |
| settlement_bank / supplier_bank | string | Bank / Branch Name | Normalize to "XX Bank" format via script |
| settlement_bank_account / supplier_bank_account | string | Bank Account Number | Sensitive — encrypt in transit, mask at rest |
| Large-payment bank code | string | Large-payment Routing Code | When value is the literal string 'null', must be cleared before sending |
| Is Agricultural Bank | bool | Whether ABC | Determined by substring "农业银行" in bank name |
| Bank Category | string | Normalized Bank Name | Script: strstr(value,'银行',true).'银行' |
| processCode / process_code | constant | DingTalk Approval Process ID | Inject from config / env var — never hard-code |
| originatorUserId / deptId | constant | Originator / Dept ID | Root dept passes -1, supports multi-store parameterization |
| formComponentValues | array | Form Control Values | Built from a single source record into [{name, value}, ...] |
How to Configure on QeasyCloud
On the QeasyCloud data integration platform, this interface is typically wired with a dual-adapter pattern: a source Lemeng adapter that configures the incremental window and pagination, and a target DingTalk approval adapter that configures processCode and the form_component_values template. QeasyCloud's field mapper automatically lands source fields onto target controls by name. The AfterTargetGenerate hook handles bank-name normalization, large-payment code nullification, and ABC detection. Credentials, process IDs, and originator IDs are injected through QeasyCloud's "environment variables / config center" to avoid hard-coding. The scheduler center supports 15-minute incremental runs, low-peak full syncs, and staggered queues out of the box.
Cross-Scenario Best Practices
- Suppliers first, then settlements: Supplier is master data — build the supplier profile in DingTalk first, then let settlements reference it by code; otherwise approval forms can't find the supplier.
- Stagger by 2–5 minutes: The two strategies have no hard dependency, but concurrent runs can trigger DingTalk throttling — staggered triggering is the safe play.
- Bank fields are the danger zone: Opening bank, branch, and bank-category fields vary across customers (
supplier_bank/account_bank, etc.). You must confirm the actual API path during implementation and unify via script. - Large-payment code as
'null'string: Lemeng often returns empty values as the literal string'null'. Passing it directly to DingTalk breaks validation — nullify upstream first. - Idempotent writes: Target side deduplicates by
supplier_settlement_noandsupplier_numto prevent duplicate approval instances on re-runs. - Multi-store parameterization:
branch_numshould be parameterized to fit multi-store retail chains.
Pitfall Postmortems
- Bank-name script crashes halt the whole batch: A single record's script exception can break the loop. The safe pattern is try/catch isolation: log the failure, fall back to the original value, and never let one bad record take down the batch.
- DingTalk 429 throttling: Frequent under high concurrency. Configure a 60s wait / max 5 retries and enable QeasyCloud's sharded queues.
- Hard-coded
processCode: Sharing one process across stores or business lines causes data cross-contamination. Maintain multipleprocessCodeper business line and inject via the config center. - Incremental window too narrow, missing data: Using creation time can miss backfills or re-entries. Prefer audit time as primary and
last_edit_timeas backup. - Sensitive fields stored in plaintext: Bank accounts and holder names stored without masking. HTTPS in transit plus masking at rest is the minimum bar — QeasyCloud's field-level masking rules can be turned on directly.
When to Choose This
Best for mid-to-large chain and supply chain enterprises where the business system is the system of record and OA is the approval entry point: supplier master data needs approval and audit trails in OA, and settlement documents need to flow through DingTalk's exported document process. If the OA is already unified on another platform, or there is no need to push master data into the approval flow, this solution doesn't apply — use one-way data distribution or BI extraction instead.