Sales Outbound Order API Field Handbook: Aggregated Practice from Wangdiantong to Chanjet T+
What Problem Does This API Solve
In retail and e-commerce operations, the sales outbound order in the ERP system is the core voucher connecting orders, inventory, and finance. A common pain point we have encountered across customer projects is that outbound orders generated in Wangdiantong need to be synchronized to Chanjet T+ in near real-time to create sales delivery vouchers, which then drive invoicing and reconciliation. The QueryStrategyData API is specifically designed to pull outbound data incrementally by strategy and time window, and combined with scheduled tasks it achieves near real-time data aggregation.
API Capability Overview
- Authentication: Internal strategy token within the Qeasy (轻易云) Data Integration Platform; no need to expose source system credentials.
- Request Method: RESTful POST, method name
QueryStrategyData. - Core Request Parameters:
strategy_id(plan ID, distinguishing different account sets),status(data status filter, e.g.0,6means waiting and queued),created_at_begin/end(incremental time window),page,pageSize,projection(project fields on demand). - Response Structure: JSON array, each record is an aggregated outbound order containing primary keys, detail list, and status code.
- Pagination and Incremental: Supports page+pageSize pagination; recommended to combine
created_attimestamp as incremental cursor; scheduled task*/10 * * * *runs every 10 minutes. - Multi-Account Set Isolation: Different
strategy_idvalues distinguish 002 account set, 001 account set and other independent data sources.
Typical Field Mapping
| Field Name | Type | Meaning | Practical Notes |
|---|---|---|---|
| stockout_no | string | Outbound order number | Business primary key; preserve prefix when mapping to Chanjet T+ ExternalCode |
| stockout_id | string | Outbound order internal ID | System unique identifier, used as idempotent dedup key |
| trade_no | string | Transaction/order number | Main business code in ERP, preferred for cross-system reference |
| src_trade_no | string | Mall order number | In multi-platform scenarios must combine with shop_no to identify ownership |
| warehouse_no | string | Warehouse code | Key field for warehouse mapping; translation needed if target uses code |
| shop_no | string | Shop code | From Wangdiantong to Chanjet usually maps to customer code |
| consign_time | string | Delivery time | Must be converted to consign_time_new standard format before writing to Chanjet |
| receivable | string | Receivable amount | All amount fields are string; convert via BigDecimal to avoid precision loss |
| goods_total_amount | string | Total goods selling price | Same as above, handle together with currency field |
| status | string | Outbound order status | Used in queries to filter pending data |
| details_list | string | Outbound order details | JSON structure, must be parsed line by line before mapping to delivery details |
| cs_remark | string | Customer service remark | Directly mapped to Chanjet Memo field |
| receiver_province/city/district | string | Receiver province/city/district | Keep region codes for downstream validation |
How to Configure on Qeasy (轻易云)
On the Qeasy Data Integration Platform, this API call typically adopts a "strategy data source + write target" bidirectional configuration pattern. The platform aggregates Wangdiantong raw data by account set into a strategy table. Configuration steps:
- Create a "Wangdiantong Sales Outbound" strategy in data source management, bind the corresponding account set
strategy_id. - In Qeasy's field mapper, drag source fields on the left to target fields on the right such as
VoucherDate,ExternalCode,Customer,Memoof Chanjet T+ sales delivery. - For
details_list, Qeasy automatically expands it into a sub-table and maps toSaleDeliveryDetails. - Configure scheduled task
*/10 * * * *; the platform automatically manages incremental cursors and retries.
Cross-Scenario Practice Essentials
Across multiple customer projects, we have distilled these common experiences:
- Multi-account sets require independent strategies: 002 and 001 account sets must have different
strategy_idto prevent data cross-contamination and downstream reconciliation errors. - status filtering beats full pull: Using
status=0,6to only pull waiting and queued data reduces invalid traffic by over 70%. - Amount fields must be handled as strings: Source returns string type; must convert to BigDecimal in the middleware before writing to target.
- Detail expansion is the key bottleneck:
details_listis a JSON string; the platform side must configure a JSON parser to expand line by line, otherwise details may be lost or duplicated. - Delivery time is the gold field for voucher date:
consign_timeis converted and used as ChanjetVoucherDate; format must be confirmed with finance in advance. - Idempotency relies on dual keys: Use
stockout_id+stockout_nocombination as idempotency key to prevent duplicate writes from network retries.
Troubleshooting Recap
-
Account set data crossover: A customer once misconfigured 002 account set's
strategy_idas 001's, resulting in dirty data in the 001 account set. The safe approach is to create separate strategy files per account set with strict naming differentiation. -
Amount precision loss: Source returns string
1234.5600, target writes directly to float field becoming1234.56, causing a one-cent difference during reconciliation. This is easy to fail; must explicitly declare decimal type in the mapper. -
Detail row parsing timeout: When a single order has over 500 detail lines, the platform's default parser times out. The safe approach is to pre-split large orders or enable streaming parsing in the mapper.
-
Missing region codes: Some legacy data lacks
receiver_province_code, causing downstream address validation failures. Recommend filling default values and tagging before writing. -
Incremental cursor rollback: Server clock rollback causes
created_atincremental to miss data. This is easy to fail; recommend combiningmodifiedfield as dual cursor fallback.
When to Choose
This API is suitable for near real-time synchronization of sales outbound orders between Wangdiantong ERP and Chanjet T+, especially for retail enterprises with multiple shops, warehouses, and account sets. It is not suitable for full-volume report pulling without detail expansion needs, nor for cross-year historical data batch migration — the latter is better handled via offline ETL channels.