ERP 与发货
- 可以读取
- 订单编号、付款标记、承诺发货日期、快递扫描状态
- 可以准备
- 内部发货任务和客户通知草稿
- 获批后可以写回
- 获批的发货备注或已经确认的物流编号
- 遇到这些情况停下或交回给人
- 订单无法匹配、必要字段为空、或连接暂时不可用
- 企业
- 虚构的奥克兰小型批发商
- 开始时间
- 每个工作日早上 7:30
- 访问边界
- 动作获批前保持只读
- 输出
- 晨间简报和易读的操作记录
01 输入
先读取一夜之间的变化
这次示例运行只读取当前流程需要的记录。下面的每一条记录都是模拟数据。
本页中的企业、业务记录、人员、金额和运行结果均为虚构示例，不是客户案例，也不代表已完成项目的实际结果。这里展示的是一种可能的恢复路径，不代表每套系统或每次故障都能用同样方式恢复。
- ERP 与发货SO-1842
已付款订单延迟发货
承诺发货日期是昨天，但系统里还没有快递扫描记录。
异常 - CRMSO-1848
配送资料不完整
配送规则要求填写门牌单元号，但这个字段是空的。
需要人工处理 - 库存系统SKU-042
库存低于补货规则
现有 8 件，补货点为 12 件，而且没有未完成的采购申请。
符合规则 - 财务系统与 ERPINV-614
付款状态不一致
财务系统显示已经付款，订单记录仍然显示等待付款。
数据冲突 - 共享邮箱LEAD-233
客户跟进已经到期
约定的跟进时间已经过去，系统里还没有收到回复。
可以准备草稿
连接器合同
每套系统都有明确的小任务，不是把大门全部打开
接入真实系统前，我们会为每个连接器写清允许范围。这个模拟示例逐项展示它可以读取什么、准备什么、获批后写回什么，以及什么时候必须安全停下。
CRM
- 可以读取
- 客户编号、必要配送字段、跟进日期、最后一次回复
- 可以准备
- 资料缺失异常或客户跟进草稿
- 获批后可以写回
- 在匹配记录中写入获批备注和下一步日期
- 遇到这些情况停下或交回给人
- 客户无法匹配、两条记录互相冲突、或关键字段需要人判断
库存与采购
- 可以读取
- 现有数量、补货点、未完成申请编号
- 可以准备
- 包含数量、原因和模拟估算金额的采购申请
- 获批后可以写回
- 获批订单编号和下次检查日期
- 遇到这些情况停下或交回给人
- 批准后库存记录发生变化、出现新供应商、或写回失败
财务系统
- 可以读取
- 当前检查需要的发票编号和付款状态
- 可以准备
- 附上两边数据的来源冲突异常
- 获批后可以写回
- 这个示例不写财务记录，财务系统仍是付款状态的主来源
- 遇到这些情况停下或交回给人
- 财务与 ERP 状态不一致，或无法按编号匹配发票
共享邮箱
- 可以读取
- 会话编号、约定收件人、最后回复、跟进日期
- 可以准备
- 按照确认过的话术准备跟进草稿
- 获批后可以写回
- 获批的发送结果和一条 CRM 活动记录
- 遇到这些情况停下或交回给人
- 出现新收件人、会话无法确认、或没有合适的消息规则
02 检查与判断
按照确认过的规则处理，再把常规工作和例外分开
遇到资料缺失或不同系统互相冲突时，数字员工不会自己猜答案。它只准备规则允许的动作，其余事项交给人判断。
发现这种情况数字员工可以准备控制边界
- 1发现这种情况
库存达到或低于补货点，而且没有未完成的采购申请
数字员工可以准备按照事先确认的数量准备采购申请
控制边界任何支出都必须由指定负责人批准
- 2发现这种情况
已付款订单超过发货时间，但没有快递扫描记录
数字员工可以准备内部发货任务和客户通知草稿
控制边界对外消息必须先经人工审核
- 3发现这种情况
必要字段缺失，或者两个来源的数据互相冲突
数字员工可以准备附带冲突数据的异常记录
控制边界不猜测字段，也不修改关键记录
- 4发现这种情况
跟进日期已过，而且没有收到回复
数字员工可以准备按照确认过的话术准备跟进草稿
控制边界发送前由人审核
03 动作与恢复轨迹
跟着一条库存异常走过一次写回失败
第一次获批写回没有成功。流程随即停下并保留依据，把异常交给指定负责人。只有负责人核对两边记录并批准一次受控重试后，流程才会继续。如果无法确认目标系统状态，流程会继续保持暂停。
追踪记录 · SKU-042 · 模拟恢复示例
虚构企业 · 模拟业务记录输入
早上 7:31
读取库存记录
现有库存为 8 件，老板确认过的补货点是 12 件。
检查
早上 7:33
确认没有未完成的申请
采购记录中没有 SKU-042 的有效申请。
判断
早上 7:35
匹配已经确认的补货规则
规则允许准备一份 24 件的申请，但不允许未经批准产生支出。
准备动作
早上 7:37
准备采购申请 PR-0092
申请中列出货品、数量、模拟估算金额和触发这次申请的规则。
人工批准
早上 7:47
记录运营负责人的决定
示例中的负责人批准了申请。在此之前，没有下单，也没有写回系统。
写回系统
早上 7:50
第一次获批写回失败
采购接口因为缺少一个订单必填字段而拒绝了这次请求。系统没有返回采购单编号，因此流程记录错误，并立即暂停所有依赖这次写回的后续动作。
上报异常
早上 7:51
把异常和依据交给运营负责人
异常记录保留获批申请、来源记录版本、尝试写入的内容、时间、目标系统返回信息和本次运行编号。
人工核对
早上 7:56
由人核对两边记录再决定是否恢复
负责人确认目标系统没有生成订单，补齐缺失字段，并核对来源记录、供应商、数量和金额都没有变化，然后批准一次受控重试。如果业务数据已经变化，就必须重新批准。
核验写回
早上 7:58
重试一次，读回结果并完成对账
连接器创建 PO-7714，从采购系统读回编号，再把已确认的编号和下次检查日期写入 ERP 记录。
04 写回、恢复与审计
失败尝试和核对后的结果都会留在记录里
这份跨系统操作记录不会把失败尝试悄悄改成完成。它会保留暂停原因、交给负责人的依据、人工恢复决定和最后的读回结果。所连接的系统也可能保留自己的操作记录；是否提供、覆盖到什么程度，会因产品、动作、配置和套餐而不同。
| 时间 | 执行者 | 对象 | 动作 | 状态 |
|---|---|---|---|---|
| 7:31 | 数字员工 | 库存 / SKU-042 | 读取现有数量和补货点 | 只读 |
| 7:33 | 数字员工 | 采购记录 | 检查是否已有未完成申请 | 没有找到 |
| 7:37 | 数字员工 | PR-0092 | 准备采购申请并附上原因 | 等待批准 |
| 7:47 | 运营负责人 | PR-0092 | 批准建议支出 | 已批准 |
| 7:50 | 数字员工 | ERP / SKU-042 | 尝试获批写回，目标系统拒绝了一个必填字段 | 已暂停 |
| 7:51 | 数字员工 | 运营负责人 | 发送记录版本、申请内容、错误和运行编号 | 已通知负责人 |
| 7:56 | 运营负责人 | PR-0092 | 确认目标系统没有订单，补齐字段并批准一次重试 | 已批准恢复 |
| 7:58 | 数字员工 | 采购系统 / PO-7714 | 重试一次，读回采购单，并记录已经确认的编号 | 已完成对账 |
05 晨间简报
老板看到的是要做的决定，不是又一个后台
早上 8:00，示例运行把所有工作整理成异常、待批准事项和已经完成的动作。
- 3 个异常需要关注
- 2 个动作草稿等待审核
- 1 次写回失败已经暂停、人工核对并完成对账
- 1 个数据冲突仍然等待人工处理
- 0 个动作在缺少必要批准时执行
本页所有数量、业务编号、金额、决定和时间均为模拟示例数据。
我们如何搭建这套系统
先用现有系统原生能力，只为确认的缺口增加连接
我们会先核实现有系统和可用连接本身已经能做什么。只有确实存在交接缺口、所需访问条件已经验证，而且书面范围包含这段连接，BestAI 才会针对这段交接开发或配置专门服务该流程的 API 连接器。接入真实数据前，双方会先确认流程可以读取什么、可以准备什么、哪些动作必须由人批准，以及每个结果要写回哪里。
- 现有系统的原生能力能满足约定记录和控制要求时，优先继续使用
- 访问范围只包含这条流程需要的字段和动作
- 连接真实记录前，先测试规则和例外情况
- 遇到写回状态不清时先暂停并核对两边系统，由指定负责人批准后再继续
- 让团队清楚看到约定范围内的人工决定、关键动作和已确认结果