事业部OPS（操作系统）
否
重新提交
按照袋子渠道推送
需要加上验证：一个袋子中运单号是否相同服务商
按照运单渠道进行分组
按照运单渠道进行分组预报
否，干线渠道
是
是，推送袋子数据
运单和袋子是否渠道同一服务商
事业部客户系统
签入
修改订单
是否按照运单渠道代码分组预报
是否预报
袋子数据是否已经存在
接收异常结果
定时定量及转运都按照袋号的维度返回。老接口则直接按照总单号的维度返回
渠道A
事业部OMS（订单系统）
按照总包渠道推送
所有运单号服务商是否一致，或者cms订单上已存在
执行新的总包流程。可以支持按照袋子渠道及运单渠道拆分
开始
是，推送总单数据
总包文件上传
预报流程
渠道B
签入预报
预报数据：总单号，提单号提单号、袋号、运单号等全量数据
是否所有运单的服务商都一致
是否符合oms系统校验
接受订单执行预报
生成总包文件
否，返回cms清晰错误
否，返回异常结果
订单状态
接收袋子数据
生成追踪号及面单
是否离线
CMS预报及推送流程与上面下单的一致，对于异常处理，可能则由客户处理变为事业部处理
是，按照袋子渠道推送
CMS内部处理
装车发货
装袋
现状：此接口包含了总单号、袋子、运单号的所有信息。目前有TMS/WT事业部在使用，后续规划需要他们也切换掉。异常场景使用：目前存在需要“补签”，即订单未通过袋子数据进行的预报。需要通过此全量接口进行推送。
干线服务商
异步异常通知，无人接收、前置减少或内部处理掉
袋号，袋子渠道。运单号，跟踪号，重量等
是，推送总单所有数据
上传提单文件
客户交货
TMS/WT老接口
否，实时返回错误提示
规划:转运之后只走上述的服务商，其余的转运只是返回定时定量预报的结果及可能存在未符合定时定量规则的触发点
对于需要追踪号
返回运单号及，YT面单
是否新任务模式
结束、不推
推送结果
暂不执行
推送追踪号
转运推送
内部逻辑：查询满足服务袋子范围中运单号的渠道
下单
按照袋子渠道进行预报推送
接收结果
是，非干线渠道
接收错误提示
数据是否完整
否，按照袋子渠道推送
包裹及总包预报流程-数据流
接收追踪号及面单
任意选第一运单的渠道进行预报
接收订单 执行包裹预报规则
一个袋子中运单号是否相同服务商
原则上：只有需要发货批次实物与数据完全统一的才需要走在服务商配置上设置转运推送后续需要业务整理一份只有那些需要提单号按照实际批次预报的，其余的全部走定时定量
结束，不推
是否符合CMS内部校验
推送异常通知
返回运单号，服务商商面单
否，实时返回错误
否，推送异常通知
总包文件解析对比
CMS
否，返回服务商错误
定时定量服务（按照每个服务商设置执行）：
袋子数据是否完整
异步接收错误提示
袋子中运单服务商是否一致
原则上，只要都通过袋子预报，都可以被定时定量服务执行掉
通过袋子的渠道配置ISACI判断
否，按照总包渠道推送
返回原始及注释后的cms错误提示
面单单号识别
下单直接预报便于客户第一时间处理异常，适具体业务场景而定
预报数据：总单号，提单号、袋号、清关国家
预报未被定时定量服务预报的数据
并行判断预报
飞书预警监控未预报的袋子量
末端服务商
是否上传成功
推送追踪号及面单
更新订单状态
是否需要转运推送总包
是否需要总包预报
映射cms错误提示
袋子数据，是否不存在
通过api下单
执行旧的总包流程。注。如果是干线的，则推送了干线服务商
备注信息
地址校验前置，方便事业部客户第一时间及时修改
是否符合服务商校验
重新提交，生成新的订单id
系统配置参数及规则
面单刻画
换单
服务的频率及范围：按照袋子服务商配置判断、袋子未预报，袋子服务商的配置。 定时：按照设置值执行定量：查询袋子服务商一致的范围的运单数量
是否需要转运推送
需要找事业部处理
否。实时返回错误
是否满足定时定量服务
定时定量服务
否，返回错误
修改重新提交
是否解析成功
是，返回成功结果
是，提交服务商
