库存不足自动通知：第一次使用自动化
从商品库存低于安全线开始，让系统主动通知采购并生成待办
上一篇，我们用请假审批讲了第一个工作流。工作流适合处理"人按步骤推进"的事情：员工提交、主管审批、人事备案，每一步都有处理人、处理动作和审批历史。
但企业系统里还有另一类事情：它不应该等人发现，也不应该等人发起。
比如库存不足。仓库已经出库，商品当前库存从 120 变成 18，而安全库存是 30。如果没人每天盯着表格，这个问题可能要到客户下单、仓库拣货时才暴露。等到那一刻再通知采购，通常已经晚了。
自动化要解决的就是这种问题：当业务数据发生变化，并满足某个条件时，系统主动执行动作。
为什么工作流还不够
工作流的起点通常是"有人提交了一件事"。请假申请、合同审批、费用报销都属于这一类。
库存预警不一样。它的起点不是某个人想发起流程，而是系统发现业务数据已经进入风险区间。
如果仍然用人工方式处理，过程大概是这样：
- 仓库人员录入出库记录；
- 商品库存被更新；
- 采购人员定期打开商品表筛选低库存；
- 发现库存不足后，再手动建采购任务；
- 经理问起时，再解释为什么现在才采购。
这个过程的问题不是"没有数据"，而是"数据变化没有变成动作"。
自动化的价值就在这里：让系统在合适的时间主动推一下业务。
先准备三张表
自动化不是凭空发生的。它依赖稳定的数据源，也应该把执行结果沉淀回系统。
在库存不足这个案例里，可以先设计三张表：
|-------|--------------------------|
| 数据表 | 作用 |
| 商品表 | 保存商品基础信息、当前库存、安全库存、采购负责人 |
| 库存流水表 | 记录每一次入库、出库、盘点调整 |
| 采购待办表 | 保存系统自动生成的补货任务 |
数据关系可以这样理解：
库存自动化的数据模型
商品表回答"现在还有多少"；库存流水表回答"为什么变成这个数量"；采购待办表回答"谁要处理这件事"。
如果只修改商品表的当前库存，不记录库存流水，后面就很难复盘库存为什么突然下降。如果只发通知，不生成采购待办，采购人员看到消息后仍然要手工记录，事情还是容易丢。
自动化由三部分组成
第一次设计自动化，可以把它拆成三件事：
- 触发器：什么时候启动自动化；
- 条件：什么情况下继续执行；
- 动作：满足条件后做什么。
库存不足自动通知可以这样设计：
|-------|---------------------------|
| 自动化部分 | 本案例配置 |
| 触发器 | 商品表的当前库存发生变化，或新增库存流水后更新库存 |
| 条件 | 当前库存小于安全库存 |
| 动作 1 | 通知采购负责人 |
| 动作 2 | 创建一条采购待办 |
| 动作 3 | 记录自动化执行日志 |
这条链路可以概括为：
库存不足自动通知触发链路
这里最重要的不是"能发消息"，而是把触发、判断、执行和记录连起来。否则自动化很容易变成一个看起来聪明、实际不可追踪的小脚本。
一个具体例子
假设商品表里有一条记录：
|-------|------|
| 字段 | 值 |
| 商品名称 | 物料 C |
| 当前库存 | 120 |
| 安全库存 | 30 |
| 采购负责人 | 张小明 |
一次出库后，系统新增库存流水：
|------|------------------|
| 字段 | 值 |
| 关联商品 | 物料 C |
| 变动类型 | 出库 |
| 变动数量 | -102 |
| 发生时间 | 2026-08-02 10:30 |
商品当前库存被更新为 18。自动化检测到：
当前库存 18 < 安全库存 30于是系统执行三件事：
- 给采购负责人张小明发送库存预警通知；
- 在采购待办表创建一条"物料 C 需要补货"的任务；
- 写入一条自动化执行日志，记录触发时间、触发商品、执行结果和关联待办。
这样，库存不足不再停留在表格里，而是变成了明确的业务动作。
通知只是开始，待办才让事情闭环
很多自动化设计会停在"发通知"。
这当然有用，但还不够。通知适合提醒，待办适合追踪。
如果系统只发了一条消息，采购负责人看过之后是否处理、什么时候处理、处理到哪一步，系统并不知道。消息会被新消息淹没，后续也很难统计"本周出现了多少次库存预警"。
更好的做法是：通知和待办一起生成。
采购待办至少应该包含：
|-------|-----------------|
| 字段 | 说明 |
| 关联商品 | 哪个商品库存不足 |
| 当前库存 | 触发时的库存数量 |
| 安全库存 | 判断阈值 |
| 建议采购量 | 可按安全库存或目标库存计算 |
| 负责人 | 谁要处理 |
| 状态 | 待处理、处理中、已完成、已关闭 |
| 来源 | 自动化生成 |
这样，通知负责把人拉回系统，待办负责让事情继续被管理。
自动化也要可追踪
自动化最怕"悄悄失败"。
比如通知接口异常、负责人为空、采购待办创建失败、条件配置太宽导致重复触发。如果没有日志，用户只会觉得"系统有时候灵、有时候不灵"。
所以自动化应该留下执行记录：
- 哪条数据触发了自动化；
- 当时的关键字段值是什么；
- 条件是否成立；
- 执行了哪些动作；
- 每个动作成功还是失败；
- 如果失败，失败原因是什么；
- 是否产生了采购待办或通知记录。
对开发者来说，这就像后台任务日志。业务人员不一定关心技术细节，但系统必须能回答：这次为什么触发、触发后做了什么、有没有成功。
自动化和工作流有什么区别
工作流和自动化经常一起出现，但它们解决的问题不完全一样。
|-----|------------------------------|
| 能力 | 更适合解决的问题 |
| 工作流 | 多人按步骤处理，有审批节点、有当前处理人、有流转状态 |
| 自动化 | 数据变化后系统主动执行动作，例如通知、创建记录、更新字段 |
请假审批是典型工作流，因为每一步都需要人做判断。库存不足是典型自动化，因为系统可以根据库存和安全库存直接判断是否要提醒。
当然，两者也可以组合。库存不足先自动生成采购申请，再进入采购审批工作流。这时候自动化负责"发现问题并发起动作"，工作流负责"让采购申请按规则走完"。
常见误区
第一个误区是条件写太宽。只要库存变化就通知，会让负责人很快对提醒麻木。应该只在库存低于安全线、且没有未完成采购待办时触发。
第二个误区是只发通知不建记录。通知解决提醒，记录解决追踪。企业系统不能只追求"响一下"。
第三个误区是不考虑重复触发。库存连续变化时，系统可能重复生成多个相同待办。可以通过"同一商品存在未完成采购待办时不再创建"来避免。
第四个误区是没有失败处理。自动化失败不是小事，至少要有日志，必要时还要通知管理员或允许人工重试。
从自动化走向定时任务
到这里，我们已经完成了第一次自动化：库存变化后，系统判断是否低于安全库存，并主动通知采购、生成待办、记录执行结果。
但并不是所有自动动作都来自"某条数据刚刚变化"。
有些任务更适合每天、每周、每月定时执行。例如每天早上生成今日待办、每周一汇总逾期客户、每月初提醒合同即将到期。