## 采购订单交付跟踪与逾期预警 {.case data-case-id="058"} | 字段 | 值 | | --- | --- | | 案例编号 | `058` | | 行业 / 部门 | 制造 / 采购 | | 角色 | 采购专员 | | 难度 | `进阶` | | 调用来源 | `schedule`（定时由获授权 Agent 经 App/Extension 读取 ERP 订单与收货记录） | 采购单下出去之后交付全靠人工盯：哪张单该到了、哪张已经逾期、需求方还等着用，采购专员却要一张张翻 ERP 才知道。目标：定时让获授权 Agent 经 App/Extension 读取 ERP 的在途采购订单与收货记录，逐单比对承诺交期与实际收货：已交付的归档发回执，未到期的正常跟踪，逾期的生成预警清单，经采购专员确认后再分别通知供应商对接人与需求方。逾期判定只认系统时间戳，承诺交期或收货日期缺失的单不猜，单列"待确认"；供应商名称一律脱敏为内部代号，通知对象仅用系统字段，缺失标"待确认"。本流程只做比对与提醒，不改单、不通知未经确认的内容。指标：逾期订单从判定到采购专员收到预警清单的中位数 ≤ 2 小时；逾期判定 0 例来自缺失或猜测的日期；通知对象 0 例来自猜测。 - **覆盖**：定时读取订单与收货记录、逐单比对承诺交期与实际收货、四类结果分流、逾期经确认后通知供应商对接人与需求方（对象缺失标"待确认"）。 - **不覆盖**：改单或改交期、自动向供应商发送任何信息、自动触发索赔或考核、替代 ERP 的库存对账。 - **假设**：有一个经授权能读取 ERP 订单与收货记录的 Agent（通过 App/Extension）；订单含单号、内部代号、承诺交期、需求方与供应商对接人字段；供应商名称一律用内部代号呈现。 把下面这段发给 Loop，它会在后台帮你创建这个 Workflow： ```text 帮我创建一个 Workflow：每日定时由获授权的查询 Agent 经 App/Extension 读取 ERP 的在途采购订单与收货记录，App/Extension 在读取侧即完成代号化，Agent 只接收单号、供应商内部代号、承诺交期、实际收货、判定类别等白名单字段，逐单比对承诺交期与实际收货并回传。逾期判定只用系统时间戳，不基于单边数据判定：承诺交期或收货日期缺失的单不猜，单列"待确认"；供应商名称一律脱敏为内部代号。 触发：定时（计划）发起调用，调用时带入平台/调度器签发且原样传递的 `period_key`、团队频道、查询 Agent 和审批人（采购专员）；Agent 不根据执行时刻铸造周期。 结果分四类处理： 已交付（收货记录齐全且覆盖订单数量）：归档发回执并留审计时间戳。 未到期（系统时间未过承诺交期且无逾期判定）：正常跟踪，汇总进回执并留时间戳。 逾期（系统时间已过承诺交期且收货不足）：生成预警清单（单号、内部代号、逾期天数、缺失日期单列"待确认"），交采购专员确认后再通知供应商对接人与需求方——通知由获授权 Agent 经 App/Extension 发出（执行方为 Agent，人在采购系统的改单动作不在本流程）；发送目标只用该采购单号在系统登记的对接渠道，对接人与需求方仅用系统字段，缺失标"待确认"、通知对象留空待人工补，绝不猜测；通知内容供应商只用内部代号。对每一条逾期通知执行完整副作用契约：业务键=采购单号+平台签发的 period_key+期望变化（通知供应商对接人或需求方）+目标渠道（两类通知各自一键），同一键只发一次；响应未知时先查发送记录再决定是否重发，不重复发送；发送失败按重试上限有限重试，仍失败则升级值班频道并置"待处理"保留待发内容供人工补偿；每次发送留审计时间戳。驳回则不通知留审计，本次失败结束。 本期无在途订单（查询成功但订单为空）：发"本期无在途订单：发汇总回执并留时间戳，不静默结束"的零结果回执，不当作取数失败。 审批：逾期预警清单必须经采购专员确认后才通知供应商对接人与需求方；审批为二值确认或驳回，不设自动超时，无默认通过/否决；驳回即不通知留审计，没有自动改判。 取数失败（ERP 不可达或订单、收货任一侧数据陈旧）：告警失败、留审计时间戳，按重试上限重试，仍失败则升级到值班频道；不基于单边数据做任何判定，也不当作"本期无在途订单"。 异常：查询 Agent 回传不合结构就停在等待点等它重新提交，不自动重跑；通知发送失败按重试上限重试，仍失败则升级到值班频道并保留待发内容供人工补发。取消只停止尚未调度的后续图，不召回已发通知、不自动补偿；保留 Effect 与外部 receipt，恢复时按完整业务键查询权威状态，由恢复 Owner 决定保留结果、另建补偿行动卡或升级。 完成：归档、跟踪汇总、逾期通知、驳回、零结果回执、取数失败升级各自留审计时间戳后结束。 ``` ![案例 058 采购订单交付跟踪与逾期预警：定时让获授权 Agent 读取 ERP 订单与收货记录逐单比对承诺交期与实际收货；已交付归档发回执，未到期正常跟踪，逾期生成预警清单（缺失日期单列待确认、供应商用内部代号）经采购专员确认后由获授权 Agent 经 App/Extension 通知供应商对接人与需求方（目标只用该采购单号登记的对接渠道、对象仅用系统字段缺失标待确认，业务键=采购单号+平台签发 period_key+期望变化+目标渠道、响应未知先查发送记录再重发），驳回不通知留审计，本期无在途订单发零结果回执，ERP 不可达按取数失败告警留审计重试升级且不基于单边数据判定；回传不合结构停在原等待点](../../../media/cases/fig-case-058-01-flow.svg){#fig-case-058-01 width=92%} 如上图所示，正常路径、人工决策与异常同时可见： 1. **定时触发**：计划到点（每日）发起一次调用，带入平台/调度器签发且原样传递的 `period_key`、团队频道、查询 Agent 与审批人（采购专员）；Agent 不推断周期。 2. **比对订单与收货**：获授权 Agent 经 App/Extension 读取 ERP 的在途订单与收货记录，App 在读取侧完成代号化，Agent 只接收白名单字段，逐单比对并回传（单号、供应商内部代号、承诺交期、实际收货、判定类别）；回传结构不合要求时停在原等待点，等其重新提交，不自动重跑。 3. **四类结果分流**： - **已交付**：收货记录齐全且覆盖订单数量，归档发回执并留审计时间戳。 - **未到期**：系统时间未过承诺交期，正常跟踪，汇总进回执并留时间戳。 - **逾期**：系统时间已过承诺交期且收货不足，生成预警清单（单号、内部代号、逾期天数；缺失日期单列"待确认"），交采购专员确认后再通知供应商对接人与需求方——发送目标只用该采购单号登记的对接渠道，对象仅用系统字段，缺失标"待确认"、通知对象留空待人工补，绝不猜测；业务键=采购单号+平台签发的 `period_key`+期望变化（通知供应商对接人或需求方）+目标渠道，同一键只发一次，响应未知先查发送记录再决定是否重发；驳回则不通知留审计，本次失败结束。 - **本期无在途订单**：查询成功但订单为空，发零结果汇总回执并留时间戳，不静默结束，也不当作取数失败。 4. **取数失败**：ERP 不可达或订单、收货任一侧数据陈旧，告警失败、留审计时间戳，按重试上限重试，仍失败则升级到值班频道；不基于单边数据做任何判定。 你不需要手写代码或配置。把上面的提示词发给 Loop，AI 会理解意图、在后台画出这个"定时比对 + 四路分流 + 逾期人工确认"流程——它知道"比对订单与收货"需要一个发消息并等待回调的 Agent 环节、"分四类结果"需要一个条件路由、"逾期确认"需要一个审批环节、"归档回执、通知与零结果回执"各需要一个发消息环节。AI 还会在后台校验流程结构是否完整，你不必关心这些技术细节。 - **基于单边数据误判逾期**：最危险的错误。规则要求订单与收货两侧数据齐且新鲜才做判定，任一侧缺失或陈旧即按取数失败处理，绝不拿收货侧为空就断定逾期。 - **承诺交期或收货日期缺失**：不猜日期、不用同类订单均值补，单列"待确认"进预警清单，由采购专员确认时补全。 - **供应商对接人或需求方缺失**：Agent 不从联系人目录或历史记录猜对象，通知中该字段标"待确认"、通知对象留空待人工补。 - **ERP 不可达或数据陈旧**：不当作"本期无在途订单"或静默结束，而是告警失败、留审计时间戳，按重试上限重试；仍失败则升级到值班频道由人工确认。 - **采购专员驳回预警**：不通知、留审计，本次失败结束；要再发就重新确认一次，没有"AI 自动改判"。 - **通知发送失败**：按重试上限重试投递；超过上限则升级到值班频道，并保留待发内容供人工补发。 - **取消后的通知结果**：取消不召回已发通知，也不自动补偿；保留 receipt，恢复时按“采购单号 + period_key + 期望变化 + 目标渠道”查权威发送状态，由恢复 Owner 决定保留、另建补偿行动卡或升级。 - **本期无在途订单（结果为 0）**：仍发一条零结果汇总回执并留时间戳，让"没消息"变成可核验的记录。 - **查询 Agent 回传不合结构**：本次完成请求被拒绝，停在等待点等其修正后重新提交，不自动重跑。 - **长时间无人审批**：审批本身不设自动超时，流程停在等待状态。若业务需要响应时限，由另一条定时检查的 Workflow（或值班人员）扫出超时项并通知采购专员。 逾期预警必须经采购专员确认后才通知供应商对接人与需求方——对外和对内的每一条逾期通知都带着采购专员的名字，所以这一步不能省。确认时采购专员能看到单号、内部代号、逾期天数与判定依据（系统时间戳对比），缺失日期与缺失对象都标着"待确认"，是"有依据的快速决策"而非盲目转发。审批只有确认或驳回两种结果，驳回即不通知留审计，没有"AI 自动改判"，审批也不设时限。 本工作流对 ERP 订单与收货记录的读取由获授权 Agent 通过 App/Extension 完成，工作流本身不直接调用外部系统，也不改 ERP 单据。团队频道、审批人作为调用输入提供；ERP 的访问凭据用 `` 占位，由 Agent 运行时从密钥引用。ERP 不可达或任一侧数据陈旧属于取数失败，走失败回执与升级。对供应商对接人与需求方的通知是本流程唯一的外发动作，由获授权 Agent 经 App/Extension 发出：发送目标只用该采购单号在系统登记的对接渠道；业务键=采购单号+平台签发的 period_key+期望变化（通知供应商对接人或需求方）+目标渠道，同一键只发一次；响应未知时先查发送记录再决定是否重发，不重复发送；失败按重试上限有限重试，仍失败升级值班并置"待处理"保留待发内容供人工补偿，全程留审计；取消只停止尚未调度的后续图，App/Extension 保留外部 receipt，并支持恢复 Owner 按完整业务键读取权威状态后决定保留、补偿或升级；除此之外工作流不写 ERP、不改单。对供应商的沟通遵循最小披露：通知中供应商名称一律用内部代号，对接人仅用系统字段，缺失标"待确认"。进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的字段以白名单为准（仅令牌化/白名单字段，原值不进入以上任何一层），供应商实名在源头即被代号化，并按 10% 抽查四层实际记录。 - **回放集与基准**：取最近 3 个月 60 张历史订单（含已交付、未到期、逾期、日期缺失）回放，人工基准答案为按系统时间戳推算的判定清单；每日全量回放并记录扫描、确认与通知时间戳。 - **判定一致率**：四类判定与基准一致率 ≥ 98%；逾期判定 0 例基于缺失或猜测的日期。 - **单边数据防线**：ERP 任一侧数据陈旧或缺失的当期，做出逾期判定的次数为 0，100% 按取数失败处理。 - **对象字段**：系统字段提供对接人与需求方时 100% 原样带出；缺失时 100% 标"待确认"、通知对象留空待人工补，不出现猜测对象。 - **通知幂等**：对同一采购单号、`period_key`、期望变化与目标渠道重复触发 3 次，发出的逾期通知数 ≤ 1；发送目标 100% 来自该采购单号登记的对接渠道；"对方已接收但本地超时"样本 100% 先查发送记录再决定重发，重复发送 0 例。 - **源头脱敏**：进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的字段 100% 在白名单内（仅令牌化/白名单字段，原值不进入以上任何一层），供应商实名出现 0 次，按 10% 抽查四层实际记录。 - **脱敏抽查**：每周抽查 5 条通知，供应商名称 100% 为内部代号，不出现供应商商业信息。 - **结果可见**：归档回执、跟踪汇总、逾期通知、驳回失败、零结果回执、取数失败告警各自 100% 有可见回执；逾期从判定到采购专员收到预警清单的中位数 ≤ 2 小时。 - **取消恢复**：在通知请求已发出后取消的回放中，已发通知 0 次被召回或自动补偿，receipt 保留率 100%；恢复 Owner 100% 按完整业务键查询权威状态，并明确选择保留、另建补偿行动卡或升级。 ### 复用与变体 - **同构迁移**：委外加工交付跟踪、设备维保到期跟踪、样品打样进度跟踪。 - **分级预警**：逾期天数超阈值的订单在确认后同步抄送采购负责人，普通逾期只通知对接人与需求方。 - **对账衔接**：确认后再加一个 Agent 环节，由它通过 App/Extension 把逾期事实写回供应商绩效台账，仍由人确认；写回须是获授权 Agent 经 App/Extension 的幂等动作（业务键=采购单号+平台签发的 period_key+期望变化+目标台账），响应未知先查后写、按重试上限有限重试、失败升级值班并置"待处理"保留补偿，全程留审计。若不需要写侧能力，改为只读汇总或仅留 Loop 回执更安全。