WDT Sales Order Line Detail Interface Field Handbook: Authoritative Tutorial from API to MySQL Table

What Problem Does This Interface Solve

In supply chain integration from WDT to MySQL, the line items of "completed" sales orders are the most critical downstream analytics data. The header tells you "which order," while each line in detail_list represents the actual SKU-level detail — SKU, specification, quantity, unit price, allocated shipping, line-level discount, payment and delivery status, and so on. This interface incrementally syncs the line items of status=2 sales orders into a MySQL table body, supporting localized reporting, profit accounting, inventory occupancy tracking, and platform reconciliation.

Interface Capability Overview

• Authentication: Invoked through the QueryStrategyData adapter encapsulated by the Qeasy Cloud Data Integration platform. Internal signing and session management are handled by the platform — no need to worry about tokens or signatures.
• Request Structure: Core parameters include status=2 (completed), response_at_begin / response_at_end (10-digit Unix timestamp window), and page_no / page_size (pagination parameters).
• Response Structure: Returns an array of order header objects, each containing an embedded detail_list array. The actual data to land in the database is each line within detail_list; header fields serve as context.
• Pagination & Incremental Mode: Time-windowed incremental based on response_at, typically a 15-minute cycle. Across cycles, the F_response_at timestamp is used as the watermark for miss/duplicate prevention.

Typical Field Mapping

Header Key Fields

Platform Extension Fields (F_ prefix)

Line Item (detail_list) Key Fields

How to Configure on Qeasy Cloud

On the Qeasy Cloud Data Integration platform, this interface is typically configured using a two-stage approach: strategy adapter + field mapper.

1. Source Adapter: Choose "WDT · Flagship Qimen" as the source, enable the QueryStrategyData strategy query, and set status=2 along with the time window parameters. The platform automatically handles signing, rate limiting, and pagination.
2. Field Mapper: For line items, flatten detail_list[*] into a flat structure and map each field to the MySQL table wdt_sales_trade_order_detail. Set rec_id as the upsert primary key; retain trade_id for header join. It is recommended to persist F_ prefix fields to dedicated columns for easier troubleshooting.
3. Scheduling Strategy: Configure a 15-minute cron cycle, persist F_response_at as the watermark, and let it automatically chain across cycles.

Cross-Scenario Practical Essentials

1. Line items are the real sync target: The header only provides context; the real data volume lives in detail_list. Always flatten the array during configuration, or the table body will be empty.
2. rec_id must be persisted as-is: It is the unique primary key of the table body. The Qeasy Cloud field mapper outputs it as-is by default — do not apply secondary cleansing.
3. Time window boundaries must align: response_at_begin and response_at_end should fall on pay_time or modified of completed orders to avoid missing data.
4. All amount fields are strings: num / price / order_price / share_amount etc. are all strings — cast to decimal before persisting to MySQL, otherwise aggregations will fail.
5. Prefer allocated fields over original price: For profit accounting, use share_price / share_amount rather than price / order_price, otherwise order-level discounts will be "missed."
6. Store F_ fields separately: Do not mix them into the business field table; use a sidecar table or dedicated columns for fast backtracking during incidents.

Pitfall Post-Mortem

• Pitfall 1: Treating detail_list as an ordinary field. Insufficient flattening causes the table body to contain only a header record while losing all line items. The safe approach is to explicitly flatten the array in the field mapper.
• Pitfall 2: Using price for profit-accounting unit price. After order-level discount allocation, the actual unit price is share_price; using price directly inflates profit margins.
• Pitfall 3: Wrong field used for the time window. Using trade_time as the incremental boundary also pulls in unpaid orders, causing line items and headers to have inconsistent statuses. Use pay_time or modified instead.
• Pitfall 4: Ignoring stock_state. It directly reflects inventory occupancy/release; omitting it from downstream available-inventory calculations triggers oversell alerts.
• Pitfall 5: F_ fields accidentally used in business logic. F_status and F_result are internal platform statuses; using them as business status filters produces a "all empty" phantom result.

When to Use This Interface

Suitable for local storage of completed sales order line items, profit analysis, inventory occupancy tracking, and e-commerce platform reconciliation. If you only need order headers or real-time orders, use the header strategy or a status≠2 query strategy. For refund line items, use the dedicated return-inbound linkage.