领星亚马逊订单同步至金蝶云星辰销售出库单：实战教程
这个策略解决什么问题
做亚马逊多渠道的卖家，几乎都踩过同一个坑：订单在 ERP 里是一套口径，到了财务系统又是另一套口径。我们见过一个跨境电商团队，每天几百单亚马逊订单在领星 ERP 里流转，但仓库和财务要的是金蝶云星辰的销售出库单——两边编码、商品、客户都对不齐，月底对账基本靠人肉。
这个策略要做的事很纯粹：把领星 ERP 里亚马逊多渠道的销售订单，按调度节奏拉取下来，转换成金蝶云星辰的销售出库单，并把 operation_key 设为审核状态，让单据在金蝶侧直接进入待出库/已审核流程。我们在实际项目里就是用轻易云数据集成平台（Qeasy）来承接这条链路的，从源系统抽取、中间映射、到目标系统写入，全部在一个策略里串完。
数据流向与字段映射
整体流向是单向的：领星 ERP（亚马逊订单）→ 轻易云集成平台（中间映射层）→ 金蝶云星辰（销售出库单）。
源端调用的是领星 ERP 的订单查询接口，按 start_date / end_date 区间增量拉取亚马逊订单列表，主键字段是 amazon_order_id，分页参数为 offset 与 length。目标端调用的是金蝶云星辰的销售出库单接口，主键是 id，并要求传入 operation_key 控制单据状态。
关键字段对照大致如下：
| 业务含义 | 领星 ERP（源） | 中间映射 | 金蝶云星辰（目标） |
|---|---|---|---|
| 业务单据号 | amazon_order_id | 原值透传 | bill_no |
| 客户标识 | sid | 编码映射后写入 | customer_number |
| 出库日期 | purchase_date_local | 日期格式化 | bill_date |
| 单据来源 | — | 常量注入 | bill_source = "ISV" |
| 审核状态 | — | 常量注入 | operation_key = "audit" |
| 币别 | currency | 编码映射 | currency_id |
| 商品/数量 | items[] | 表头表体分阶段写入 | sal_out_bound_entry |
这里要特别说一句：表头和表体在轻易云里走的是分阶段处理——先把表头字段落库校验，再循环表体行项目。这是轻易云客户里很常见的一种应对模式，避免一次性大报文失败后不知道是哪一行出问题。
在轻易云上如何配置
在轻易云集成平台里，这条策略的配置分三块。
源端配置：选择领星 ERP 平台，API 选 /order/amzod/api/orderList，方法 POST，增量起点用 {{DAYS_AGO_s10|date}} 这种时间宏，从当前时间往前推 10 分钟开始拉，结束时间为 {{CURRENT_TIME|date}}。date_type 默认传 1（按订购时间）。分页参数 offset 与 length 走循环器，每次推进一页，直到返回为空。
目标端配置：选择金蝶云星辰 V2，API 选 /jdy/v2/scm/sal_out_bound，方法 POST。bill_source 固定写入 ISV，operation_key 固定写入 audit，这两个都是常量。bill_no 直接绑源端 amazon_order_id，bill_date 绑 purchase_date_local 并做日期格式化。
中间映射层：这是最容易出错的地方。客户标识、商品编码、币别这三类字段在两边几乎不可能完全一致，必须做编码映射。稳妥的做法是编码映射集中管理——把客户对照表、商品对照表存到轻易云的映射表里，策略里只引用不维护。这样后期业务调整只改映射，不改策略。
实施步骤
我们建议分三步走：
第一步：增量起点校准。先在测试环境用一个固定的 start_date 拉一批历史订单，验证字段映射和编码转换是否正确。这一步不要急着上调度，先用手动触发跑通。
第二步：全量触发补齐。确认映射无误后，把增量起点改成 {{DAYS_AGO_s10|date}}，做一次全量回灌，把历史未同步的订单一次性补齐。全量跑完后，再切换到正常调度。
第三步：调度频率上线。源端调度设为 7-59/15 7-23 *（从 7:07 开始，每 15 分钟一次，到 23:59 结束），目标端调度设为 9-59/15 7-23 *（比源端晚 2 分钟开始，避免抢跑）。两个调度错峰运行，是增量与全量双轨的典型做法——日常增量靠调度跑，异常时人工触发全量补数。
踩坑复盘
- 客户编码没映射就直接透传。典型错误是把领星的
sid原样塞进金蝶的customer_number，结果金蝶侧找不到对应客户，单据直接挂起。一定要在映射层做一次查表转换。 operation_key忘传或传错。这个字段控制单据是否自动审核，传空就是暂存，传audit才是审核。实际项目里见过因为大小写或者拼写问题导致单据全部停在暂存状态的案例。date_type选错时区。领星接口支持三种时间类型（站点时间/北京时间/UTC），默认1是站点时间。如果你的业务口径是北京时间，就要改成2，否则订单日期会差一天甚至更多。- 表体行项目超过单据上限。金蝶云星辰的销售出库单表体行数有限制，遇到多商品订单时要先在轻易云里做拆分，或者确认目标系统版本是否支持大行数。
- 全量回灌时重复推送。没有幂等控制的话，全量补数会产生重复单据。轻易云里靠
bill_no做幂等键，目标接口idCheck=true，重复单据会被拒掉，但日志里会刷一片红，要提前有心理准备。
适用场景与不适用场景
适用：亚马逊多渠道订单量大、需要在金蝶侧统一做销售出库和财务核算的跨境电商；订单结构相对稳定、商品和客户主数据已在金蝶建档的场景。
不适用：订单状态变更频繁需要实时同步（这套调度是 15 分钟粒度）；金蝶侧尚未完成商品或客户主数据初始化（编码映射无处可查）；需要回写物流状态到领星的场景（本策略是单向的）。