发货通知单批量提取：
到货预约自动化的第一步

发货通知单——供应商的一纸"预告"，仓库的调度起点

发货通知单（Advanced Shipping Notice，简称ASN）是供应商在货物发出后、送达前，发给收货方的一份预告文件。它与装箱单的区别在于时间窗口——装箱单随货到，是收货员在月台对着实物清点的依据；发货通知单在货到之前就到了，是仓库做到货预约和月台调度的依据。

一张标准的发货通知单通常携带以下信息：

这些字段看起来很简单——每个字段就一个数字或一串文字。但当它乘以每天收到的供应商数量、再乘以每月的工作日，手工处理的体量就值得认真算一笔账了。

手工录入的真实成本：不只时间，还有月台拥堵

手工处理发货通知单的流程，在大多数企业里是这样的：供应商通过邮件、微信或传真发来通知单 → 仓库文员打开文件、逐字段读取 → 在WMS或Excel到货预约表中逐行录入。一张通知单大约3到5分钟——不算长。但一个对接10到15家供应商的仓库，每天可能收到8到15张发货通知单，月度总量在150到300张之间。

但时间只是可见成本。更棘手的是时间窗口——发货通知单的时效性极强。供应商上午10点发来通知，说下午3点到货。如果仓库文员正在处理另一件事，通知单在邮箱里躺了两个小时，到中午才被打开录入——月台调度已经没有调整余地了。3点到就3点到了，不管月台当时是不是已经排满。

而且，手工录入模式下，仓库很难做前瞻性调度——你只能被动响应。明天有四车货要来，但你不知道每车多少箱、哪些是大件需要叉车、哪些可以直接搬——因为通知单上的数据还没进系统。调度靠经验、靠记忆、靠"老王说这批货不多应该很快"。当数据不在一个结构化的地方，任何基于数据的调度决策都无从谈起。

五家供应商，五种格式——模板方案为什么在这里卡住了

发货通知单的格式碎片化程度，在物流单据中可能是最严重的之一。不像增值税发票有金税系统的统一版式约束，也不像采购订单多半由ERP生成而保持内部格式一致——发货通知单的格式完全取决于供应商自己的出单工具和操作习惯。

五家供应商的发货通知单，可能呈现五种完全不同的形态：

面对这五种格式，基于模板的OCR工具需要为每一种格式单独配置一个模板——供应商A的PDF模板、供应商B的手写单模板、供应商C的邮件正文模板、供应商D的Excel模板、供应商E的传真模板。五套模板的创建、测试和维护——任何一个供应商更换出单方式、升级系统、或者新签了一家供应商，模板就要新增或调整。

更麻烦的是，发货通知单不像发票那样"体量大到值得为每家供应商建模板"——每张单子来的量可能只有一两张，建的模板一年只用几十次。模板维护的单位成本在发货通知单这个场景下被放大到了不合理的水平。

这也解释了为什么很多仓库的选择是"算了直接手敲吧"——不是不知道有OCR工具，而是模板方案的投入产出比在这个场景下不成立。

自定义列名提取：一次定义，适配所有供应商格式

简录AI处理发货通知单的方式，与模板OCR有一个根本区别：它不看字段在哪，只看字段是什么。你在界面上设定一组列名——发货通知编号、供应商、物料编码、物料名称、发货数量、箱数、预计到货日、车牌号、联系电话——AI在读取每张通知单时，理解每个列名的语义含义，然后在整个页面上找到对应的值填入。

供应商A的ERP PDF上"发货通知编号"在右上角一个带框的格里，供应商B的手写单上它潦草地写在抬头，供应商C的邮件正文里它是一行"ASN: ASN20260623-001"——AI不关心位置和字体，它只关心"这是一串看起来像发货通知编号的东西"。这种基于语义理解的提取机制，让同一套列名能够适配所有供应商的所有格式，不需要为任何一个供应商单独维护模板。

关于自定义列名提取的完整机制——列名如何作为指令引导AI的搜索和提取逻辑、字段命名策略、推断列的用法——我们在另一篇文章里做了系统性的拆解，建议结合参考：如何使用自定义列提取。本文聚焦的是发货通知单这一特定文档类型的场景化应用方案。

三步操作：从供应商的PDF到统一的到货预约表

用简录AI处理发货通知单的流程，归纳起来就三步——每一步的操作对象是所有的通知单，不需要按供应商、按格式、按来源做任何分类。

单张通知单的处理速度大约5到10秒。如果每天收到10张通知单，全部处理完约一两分钟——剩下的工作是仓库管理员的专业判断：根据到货时间、箱数、物料类型，在WMS系统里排定月台时段和卸货人手。

这个流程之前，发货通知单的录入是仓库文员每天分配一两个小时来做的——通常在上午集中处理。现在这个时间段被压缩到几分钟，剩下的时间可以用来做更有价值的事情：比如在系统里主动查看未来两天的到货安排，提前协调加班或临时工。这种从前瞻角度做调度管理的能力，只有在基础数据已经结构化之后才存在。

输出结果是什么样的——以及怎么用它做月台调度

提取完成后，输出是一张结构统一的Excel表格。不同供应商、不同格式的发货通知单数据全部汇总在同一张表里，每一列的含义清晰一致：

有了这张表，月台调度就从一个"经验活儿"变成了一个"数据活儿"：

• 按预计到货日筛选：一目了然今天、明天、后天各有几车货要收。哪个时段密集、哪个时段空闲——调度员不用翻通知单也能一眼判断。
• 按箱数排序：箱数多的大货安排大型月台和叉车，箱数少的小货安排快速通道——设备和人力的分配有据可依。
• 按物料类型分组：同类物料集中收货，减少仓库内部二次搬运。如果是需要质检的物料（精密件、化学品），也能提前通知质检组做好准备。
• 车牌号和联系电话：发给门卫做车辆放行登记。司机提前到了、找不到月台、需要改时间——一个电话就能沟通，不用满世界找那张通知单。

这张到货预约表与后续的收货核对环节天然衔接——货物实际到达时，收货员拿这张表对着实物清点。关于收货核对的完整工作流——如何将发货通知单数据与实际到货做比对、标记差异，可以参考收货核对数据提取。从通知到核对，形成完整的收货数据闭环。

与WMS和ERP的对接：不要指望一套系统解决全部问题

一个现实情况需要说明：简录AI不直接对接WMS或ERP系统的API——它做的事情是在"纸质/图片/PDF文档"和"结构化数据"之间架桥。桥的这端是你的发货通知单文件，桥的那端是一张Excel表。从Excel表到你的WMS月台预约模块，需要走系统自带的导入功能。

但这并不意味着"多了一步"。实际情况是：

• 列名对齐即可：在简录AI里设定列名时，直接用WMS月台预约模块的字段名——比如系统里叫"预约到货日期"，你就在列名里写"预约到货日期"。导出的Excel列名与系统字段一一对应，导入时不需要再做字段映射。
• 大部分WMS都支持Excel导入：主流WMS（SAP EWM、蓝桥、科箭、通天晓、富勒等）都支持从Excel导入到货预约单。这原本就是仓库日常操作的一部分——你只是把数据来源从"手工录入"变成了"AI提取+导入"。
• 时效窗口仍然在：从供应商发出通知单到AI提取完成、到导入WMS做月台预约——这整个过程可以在几分钟内完成。相比手工模式下可能发生的"通知单在邮箱里躺半天"的延迟，这个流程的时效优势是根本性的。

如果企业有IT开发能力，也可以通过CSV或JSON格式的导出文件，结合WMS的API做自动化对接——这条路是开放的，但需要企业自己走。简录AI负责的是"把纸面数据变成结构化数据"这一步，也是目前大多数仓库自动化缺口最大的这一步。

发货通知单在整个入库链路中的位置

发货通知单不是孤立的——它是采购入库链路的一个节点。理解它在整条链路中的位置，有助于你判断哪些环节还需要配套自动化：

发货通知单是这条链路中最早进入仓库视野的单据。它的数据质量直接影响下游环节——如果通知单上的物料编码录错了，收货核对时会发现不对；如果箱数写少了，月台排班时间不够，后面一车就得等。把发货通知单的数据提取质量守住，整条入库链路就有了一个干净的数据起点。

链路上后续两个环节——收货核对和发票对账——我们也分别做了场景化方案：收货核对——如何将发货数量与实际到货做比对，以及货运发票批量提取——月底几百张发票的对账方案。三篇文章合在一起，覆盖了从"供应商说要发货"到"财务付完款"的完整数据流。

常见问题

发货通知单数字化之后，仓库管理的下一步

本文的核心逻辑可以用一句话概括：发货通知单的批量提取不是在"省时间"——时间当然会省，但更重要的是它在"抢时间窗口"。通知单上的数据越早进系统，仓库就越有可能做前瞻性调度而不是被动应对。月台拥堵、司机排队、收货员临时找叉车——这些问题很大程度上不是资源不够，而是信息到达仓库的时间太晚、且没有被结构化。

把发货通知单数据数字化之后，仓库有能力看到的信息维度会多一个数量级：未来三天的到货物料构成、哪个时段月台负荷最高、哪些物料需要提前协调质检资源。这些管理动作的门槛不是WMS的功能——大多数WMS都支持这些——门槛是"数据有没有进系统"。

如果你同时还在手工处理货运发票的月底对账，可以看一下我们之前写的货运发票批量提取方案——逻辑一致，场景不同。把通知单和发票两端的自动化接上，从"供应商说发了货"到"财务付了款"的整条链路，手工环节还剩下两个：专业判断和异常处理。这两个本来就是系统做不了、也不应该替人做的。