Dynamics 365定时线路少了一张销售订单，先核对这几层条件

Dynamics 365 Supply Chain Management 的定时运输线路没有带入某张销售订单，不能只凭客户邮编相同就认定系统漏单。微软官方文档说明，Load building workbench依据销售订单的客户地址、交货日期和可用定时线路提出装载建议；具体匹配还会考虑选定日期范围以及装载模板容量。[1]

先把三个对象区分开。线路计划描述经过哪些枢纽和运输分段；线路指南定义装载与计划的匹配条件；定时线路则为预定计划加入发运日期安排。文档指出，线路时刻表用于生成实际线路，并不是仅建立一个计划名称，所有订单就会自然进入建议结果。排查时，记录当前选用的实际线路及相关计划，比只核对显示名称更有意义。

接着查看订单本身。在生成建议时，系统检查未结销售订单的交货地址与交货日期：地址邮编需要与计划中的枢纽邮编匹配，交货日期需要处于当前条件选择的范围。这里说的是该订单用于交付的地址，不宜仅凭客户主档上的另一个地址作判断。可将界面上实际使用的地址和日期记录下来，与本次筛选条件逐项比对。

日期范围也容易被忽略。文档说明，工作台默认带入线路值，但起始日期可以选择得早于线路上的起始日期。因此，同一条线路在不同筛选范围下得到的建议未必相同。排查记录中适合保留当次筛选，而不是事后根据线路名称回想当时条件。

最后看容量。官方说明一次只提出一个装载建议，并考虑装载模板的容量；某订单未被包括时，可能需要不同模板或额外一次配送。这里描述的是软件功能条件，不意味着可以直接把模板容量改大。实际车辆、容器及运输安排仍应由业务人员确认，避免为了让订单出现在列表中而写入不实容量。

一次有用的排查记录，可以同时保存订单编号、交货地址与日期、线路枢纽、本次日期筛选、模板和建议结果。先在允许的测试环境中复现差异，再交由实施人员核查配置；本文没有登录任何企业环境，也没有确认某一具体故障原因。

当这些条件都已对齐而订单仍未进入建议时，再带着记录继续调查版本、配置或其他业务限制。这样能把问题从“邮编相同为什么不行”收敛到某一步实际条件，而不把一个可能原因直接当成系统结论。