一、先把场景说清楚：一张采购订单是怎么进来的

采购订单（Purchase Order，PO）是企业向供应商下单的凭据。 它的上游是采购需求，下游是收货、对账、付款。本章要自动化的，是它从【一张纸/一张图】变成【ERP 里的一条记录】的那一段。

先看这张单是从哪儿来的——这段最值得看，因为它决定了后面所有技术选择：

然后它要进哪儿去：ERP 的采购模块，在那里创建一张采购订单（供应商、物料、数量、单价、税率、金额、交期）。

中间那一段，就是本章要动的地方：一个人，对着屏幕，一个字段一个字段地抄。

二、这一章和前五章的根本不同：产出物从【内容】变成了【数据】

这是本章最重要的一张表。 前面五章换了好几个平台，但产出物的性质一直没变；本章第一次变了：

最后两行，是本章全部设计压力的来源。

三、最要命的那一条：错误是【延迟暴露】的

一句来自采购主管的原话，值得完整读一遍：

一批物料几十项，录错了不容易发现，等仓库收货对不上账才发现问题，再回头改单据，流程已经被卡住了。

这句话里有三个信息，一个比一个重要：

1. 发现错的地方不在录单环节——是仓库收货时对不上账才暴露的；
2. 从录错到发现，中间隔了好几天——这几天里，单据已经往下游走了；
3. 改的时候要往回改——不只是改这一张单，还有已经发的货、已经对过的账。

对比一下前五章：发一篇文章，发不出去当场就知道；被限流了第二天看数据也知道。但录错一个数量，没人会当场告诉你——它安安静静躺在系统里，直到有一天对不上。

四、手工填一张单，时间花在哪：一次真实拆解

要设计流程，先得知道时间花在哪。 把录单这件事拆成五段：

第三段特别值得注意：人看的是"内六角螺栓 M6×20"，但 ERP 认的是"M1001"。中间要查一次——而且每一行都要查一次。

下面用 Demo 把它算出来。

五、动手 Demo：手工录单工时拆解器

这是本节真正属于你自己的那部分：把一批单据的耗时逐段拆开，看看时间到底花在哪。

# -*- coding: utf-8 -*-
"""6.1.1 Demo：手工录单工时拆解器（纯标准库）
回答一个问题：填一张采购订单，时间到底花在哪一段上。
"""
import unicodedata

# 每张单：编号 / 来源 / 物料行数 / 清晰度（clear/fuzzy/shot/excel/hand）
DOCS = [
    {"id": "D1", "src": "PDF 电子单",   "lines": 10, "q": "clear"},
    {"id": "D2", "src": "传真扫描件",   "lines": 25, "q": "fuzzy"},
    {"id": "D3", "src": "微信截图",     "lines": 5,  "q": "shot"},
    {"id": "D4", "src": "Excel 报价单", "lines": 3,  "q": "excel"},
    {"id": "D5", "src": "手写送货单",   "lines": 8,  "q": "hand"},
]

# 单段工时（分钟）
FIND = 0.5            # 找单 / 打开 / 对文件名
READ = {"clear": 0.4, "fuzzy": 0.9, "shot": 0.6, "excel": 0.7, "hand": 1.2}  # 每行读字
LOOKUP = 0.6          # 每行查物料编码（在 ERP 里搜）
ENTRY = 0.3           # 每行填单
CHECK = 1.0           # 核对合计

SEGS = ["找单", "读字", "查编码", "填单", "核对"]

def wlen(s):
    """按显示宽度算长度（中文算 2）"""
    return sum(2 if unicodedata.east_asian_width(c) in "WF" else 1 for c in s)

def pad(s, w):
    return s + " " * max(0, w - wlen(s))

def cost(d):
    read = READ[d["q"]] * d["lines"]
    look = LOOKUP * d["lines"]
    ent = ENTRY * d["lines"]
    return {
        "找单": FIND,
        "读字": round(read, 1),
        "查编码": round(look, 1),
        "填单": round(ent, 1),
        "核对": CHECK,
    }

print("=" * 78)
print("一、逐单工时拆解（单位：分钟）")
print("=" * 78)
print("  %s %s %5s  %7s %7s %7s %7s %7s   %7s" % (
    pad("编号", 4), pad("来源", 14), "行数", "找单", "读字", "查编码", "填单", "核对", "合计"))
tot = {s: 0.0 for s in SEGS}
grand = 0.0
rows_total = 0
for d in DOCS:
    c = cost(d)
    s = round(sum(c.values()), 1)
    for k in SEGS:
        tot[k] += c[k]
    grand += s
    rows_total += d["lines"]
    print("  %s %s %5d  %7.1f %7.1f %7.1f %7.1f %7.1f   %7.1f" % (
        pad(d["id"], 4), pad(d["src"], 14), d["lines"],
        c["找单"], c["读字"], c["查编码"], c["填单"], c["核对"], s))

print("  " + "-" * 76)
print("  %s %5d  %7.1f %7.1f %7.1f %7.1f %7.1f   %7.1f" % (
    pad("合计", 19), rows_total, tot["找单"], tot["读字"], tot["查编码"], tot["填单"], tot["核对"],
    round(grand, 1)))

print()
print("=" * 78)
print("二、时间花在哪一段（按占比排序）")
print("=" * 78)
rank = sorted(SEGS, key=lambda s: -tot[s])
for s in rank:
    pct = tot[s] * 100.0 / grand
    bar = "█" * int(round(pct / 2))
    print("  %-6s %7.1f 分钟  %5.1f%%  %s" % (s, tot[s], pct, bar))

machine = tot["读字"] + tot["查编码"]
print()
print("  读字 + 查编码 = %.1f 分钟，占 %.1f%% —— 这两段恰好都是【机器擅长的】" % (
    machine, machine * 100.0 / grand))
print("  剩下 %.1f 分钟里，找单与填单同样是确定性动作，核对里的【异常判断】才真正需要人" % (
    grand - machine))

print()
print("=" * 78)
print("三、一处错要花多少：返工成本（错误延迟暴露）")
print("=" * 78)
FIELDS_PER_LINE = 4          # 每行 4 个字段：物料/数量/单价/税率
field_total = rows_total * FIELDS_PER_LINE
RATE_MANUAL = 0.005          # 人工字段错误率 0.5%
REWORK_MIN = 25              # 一处错返工 25 分钟（改单 + 通知下游 + 更正账）
DELAY_DAYS = 5               # 平均 5 天后（仓库收货对账）才暴露
errs = field_total * RATE_MANUAL
print("  这批 %d 行 = %d 个字段；按人工错误率 0.5%% 计，预计错 %.1f 处" % (
    rows_total, field_total, errs))
print("  每处返工 %.0f 分钟 → 这批单预计花 %.1f 分钟在返工上" % (REWORK_MIN, errs * REWORK_MIN))
print()
print("  注意：这 %.1f 分钟的返工不是当场发生的，而是平均 %.0f 天后才暴露。" % (
    errs * REWORK_MIN, DELAY_DAYS))
print("  这正是采购订单录入最麻烦的地方 —— 与【发内容】不同，错了没人当场告诉你。")

实际运行输出（真跑，不是示意）：

==============================================================================
一、逐单工时拆解（单位：分钟）
==============================================================================
  编号 来源              行数       找单      读字     查编码      填单      核对        合计
  D1   PDF 电子单        10      0.5     4.0     6.0     3.0     1.0      14.5
  D2   传真扫描件        25      0.5    22.5    15.0     7.5     1.0      46.5
  D3   微信截图           5      0.5     3.0     3.0     1.5     1.0       9.0
  D4   Excel 报价单       3      0.5     2.1     1.8     0.9     1.0       6.3
  D5   手写送货单         8      0.5     9.6     4.8     2.4     1.0      18.3
  ----------------------------------------------------------------------------
  合计                   51      2.5    41.2    30.6    15.3     5.0      94.6

==============================================================================
二、时间花在哪一段（按占比排序）
==============================================================================
  读字        41.2 分钟   43.6%  ██████████████████████
  查编码       30.6 分钟   32.3%  ████████████████
  填单        15.3 分钟   16.2%  ████████
  核对         5.0 分钟    5.3%  ███
  找单         2.5 分钟    2.6%  █

  读字 + 查编码 = 71.8 分钟，占 75.9% —— 这两段恰好都是【机器擅长的】
  剩下 22.8 分钟里，找单与填单同样是确定性动作，核对里的【异常判断】才真正需要人

==============================================================================
三、一处错要花多少：返工成本（错误延迟暴露）
==============================================================================
  这批 51 行 = 204 个字段；按人工错误率 0.5% 计，预计错 1.0 处
  每处返工 25 分钟 → 这批单预计花 25.5 分钟在返工上

  注意：这 25.5 分钟的返工不是当场发生的，而是平均 5 天后才暴露。
  这正是采购订单录入最麻烦的地方 —— 与【发内容】不同，错了没人当场告诉你。

读结果，四个值得注意的地方：

1. 单张单的耗时差异极大：D4 只要 6.3 分钟，D2 要 46.5 分钟——七倍多。 差在哪？差在行数和清晰度。D2 是 25 行的传真扫描件，读字单价 0.9、查编码要查 25 次；D4 是 3 行的 Excel，一行都不含糊。 这直接决定了一件事：本章的"批量"和第四章的"批量"含义不同——第四章的批量是【篇数】，本章的批量是【行数 × 单据数】。十张小单可能不如一张大单耗时。

2. 占比最大的两段是【读字】和【查编码】，合计 75.9%——而这两段恰好都是机器擅长的。 读字是识别要解决的（本节现状一：企业接入后识别准确率 99%+）； 查编码是确定性查表——"内六角螺栓 M6×20"对应"M1001"这件事，系统里本来就写着。 而剩下那 24.1% 里，找单和填单同样是确定性动作。 真正必须留给人的，其实只有核对里那一小撮【异常判断】（数量不对、税率奇怪、这个词系统里没有）。

3. 第三段那个 25.5 分钟很不起眼，但它才是本章的重点。 204 个字段、0.5% 错误率 → 预计错 1 处。1 处错、25 分钟返工——看起来完全可以接受。 但请注意两件事：第一，它的暴露时间是 5 天；第二，25 分钟只是【改这一张单】的成本——如果货已经收了、账已经对过了，返工要往回追好几步。 所以真正贵的不是那 25 分钟，是那 5 天里已经流出去的东西。

4. 手写单（D5）的"读字"单价是 1.2，是清晰 PDF 的三倍——但它只有 8 行，总耗时还不到 D2 的一半。 这提醒一件事："最难识别的单据"和"最耗时的单据"不是一回事。 难识别的是手写单，耗时的是长单。设计流程时要想清楚优化哪一个——本节结尾的现状一给了一个重要提示：AI 至今仍吃力的是手写连笔、差扫描件、旋转、没见过的版式。

六、哪几段能交出去：三档归属

沿用全课的判断方式，但本章第三问换了：

七、⚠️ 2026 现状：这一侧的三件事

教材 2026-06 出版，但这三件事是本课写作时的最新情况，会影响你的技术选型。

现状一：识别准确率已经很高，但它的边界很清楚

企业接入后的公开数据：订单信息提取准确率 99% 以上、人工录入工作量释放约 80%、财务对账效率提升 5~10 倍。

但"AI 至今仍然吃力"的四类情况，必须记住： - 手写连笔（尤其潦草的字迹）； - 扫描质量差的件； - 旋转、倾斜的文档； - 没见过的版式。

现状二：财务侧的合规正在快速数字化，"单据影像"第一次有了法定地位

• 《会计档案管理办法》确立的两条原则：① 符合规定的电子会计资料可以仅以电子形式归档；② 保管期限依据【内容类型】确定，不依据载体形式——原始凭证 30 年，无论它是纸还是 PDF。
• 2020 年财会 6 号文：电子凭证打印件入账的，必须同时保存电子会计凭证。
• 2026 年：数电票覆盖率已超 85%；九部委电子凭证无纸化新规 2025 年底试点、2026 年全面推开；电子会计档案的"四性检测"（真实性、完整性、可用性、安全性）成为落地要求。

这对本章的直接影响有两处： 1. 单据原图必须存下来，而且要能跟系统里的那张订单【关联起来】——后面 6.4.3 的"回挂"就是干这个的； 2. 只存影像件是不够的——以电子凭证入账的还须保存原生文件与元数据。所以别随手把原始 PDF 删掉。

现状三：RPA 在财务场景有一个真实的合规门槛

数据：超过 40% 的企业在 RPA 规模化部署阶段会遭遇不同程度的审计与合规阻碍。

四大核心风险（这几条正好是本章第五节那四条纪律的来处）：

对应的标准做法：给机器人独立唯一的身份、最小权限、凭证进保险箱（不进代码）、日志不记敏感数据、高风险节点留人工确认。

30 秒实验

把 Demo 里 D2（传真扫描件）的 lines 从 25 改成 50，再跑一次。

会发生什么：

• D2 的单张耗时从 46.5 分钟涨到约 92.5 分钟（读字 45.0 + 查编码 30.0 + 填单 15.0 + 找单 0.5 + 核对 1.0）；
• 总工时从 94.6 分钟涨到约 140.6 分钟——只改了一行数字，整批多出 46 分钟。

结论：录单的成本几乎完全由【行数】决定，而不是由【单据张数】决定。

顺着这个思路想一层：这对流程设计意味着什么？意味着"按张分任务"不是一个好办法——一张 50 行的传真件和一张 3 行的 Excel，工作量差十倍，但都是"一张单"。 更合理的做法是"按行分任务"或者"按预估工时排序"——这也正是 6.2 那节要解决的排期问题。

再想一层：这也解释了为什么"识别"这一步必须分批、必须能重跑——因为最耗时的单往往也是最容易识别失败的单（长 + 不清晰），而它们恰恰最不该阻塞整批。

常见误区

1. 【这一章就是前面几章换个平台而已】——错，产出物的性质变了。 前五章产出的是给人看的内容，本章产出的是给系统用的数据。这个差别决定了后面所有设计：终点从"公开平台"变成"公司内部系统"、错误的代价从"限流"变成"账不平"、发现错误的时间从"立刻"变成"几天后"。

2. 【识别准了就没问题】——错，识别只是三段里的一段。 本节 Demo 已经拆开了：读字（43.6%）+ 查编码（32.3%）+ 填单（16.2%）。识别解决第一段；第二段是查表、第三段是点界面，各自有各自的坑。后面 6.4.2 会专门讲"识别对了但业务上不对"这一类问题。

3. 【录错了会马上知道】——错，这是本章最危险的地方。 错误是延迟暴露的：录错一个数量，不会有人当场告诉你，要等仓库收货对不上账才发现。而那时单据已经往下游走过了。所以本章的所有校验都必须前置到"点保存之前"。

4. 【单数多才值得做自动化】——半对，决定成本的是【行数 × 单数】。 30 秒实验已经演示过了：把一张单的行数翻倍，整批工时多出近一半。所以"值不值得做"要按【月总行数】估，不是按【月单量】估——6.1.2 的收益估算器就是按这个口径算的。

5. 【ERP 填报就是点几下鼠标，没什么风险】——错，它是本章唯一真的动【账】的一步。 它涉及钱（金额、税率）、涉及审计（可追溯性）、涉及合规（职责分离）。2026 年有超过 40% 的企业在 RPA 规模化时撞上过审计或合规问题——这不是小概率事件。

• ☐ 下一节（6.1.2 采购订单智能填报助手方案价值）

相关笔记

• 知乎图文创作和发布概述 —— 上一章的起点，对照着看：一个产出内容，一个产出数据
• 案例概述 —— 七步骨架的来处，本章仍走这条骨架
• 什么是RPA —— RPA【不需要对方配合】的独特价值，正是本章能填进 ERP 的原因
• 🤖 Agent-RPA实战 · 索引 —— 全课路线图