什么是 EDI?如何让企业间的订购业务更轻松 ── 从传真、邮件、手动录入迈向数据对接
· Go Komura · EDI, 企业间交易, 订购业务, 业务效率化, 系统对接, BtoB, DX
「交易对象通过传真发来订单,负责人将其录入销售管理系统」
「打开邮件附带的 Excel,核对商品编码和数量后进行转录」
「交货后开具发票,对方也要将同样的内容录入财务系统」
在企业间交易中,同样的订单信息或账单信息,有时会被多家公司、多位负责人反复录入好几次。
而能够减少这种重复录入、让下单、接单、发货、开票等数据直接在企业之间往来的机制,就是 EDI。
一提到 EDI,或许会让人联想到大企业使用专线搭建的大型系统。但它的本质其实要简单得多。
EDI 是一种机制,让来自交易对象的信息不再需要由人重新阅读并录入,而是直接作为计算机可以处理的数据进行交换。
本文将以订购业务为例,梳理 EDI 是什么、它与传真、邮件有何不同,以及引入后企业业务会变得多轻松。
1. 先说结论
EDI 是 Electronic Data Interchange 的缩写,中文称为「电子数据交换」。
这是企业之间以事先约定好格式的电子数据,交换订单、发货通知、发票等交易信息的一种机制。
JIPDEC 将 EDI 解释为:企业或行政机构等通过网络连接计算机,自动以电子数据形式交换单据或文件的机制。
引入 EDI 的目的并非单纯地消除纸张。
其主要目的是减少以下这类工作:
- 一边看传真或 PDF 一边进行的手动录入
- 从 Excel 转录到销售管理系统
- 目视核对录入内容
- 查找订单或发票的工作
- 用来确认订单状态的电话或邮件
- 销售、库存、账单数据的重新汇总
一言以蔽之,EDI 是让原本停滞在公司与公司之间的数据能够直接流动起来的机制。
2. 没有 EDI 的订购业务中,正在发生什么
首先来看看没有使用 EDI 的订购业务。
在下单方公司,采购负责人用自家系统或 Excel 制作订单内容,将其打印成订单,通过传真或邮件发给交易对象。
在接单方,负责人核对收到的订单,并将其录入自家的销售管理系统。
之后,会制作接单确认书、发货通知、送货单、发票等,再寄回给下单方。下单方也会将这些信息录入库存管理系统或财务系统。
下单方录入订单数据
↓
打印订单・转为 PDF
↓
通过传真或邮件发送
↓
接单方核对内容
↓
在接单方系统中重新录入
↓
制作发货、开票数据
↓
下单方再次录入自家系统
在这一流程中,同样的信息会被反复录入多次。
例如商品编码、商品名称、数量、单价、交期、送货地点等。
最初的订单数据其实已经存在于下单方的计算机中了。尽管如此,由于被转换成纸质文件或 PDF,接单方还是需要由人重新阅读,再重新录入到计算机里。
问题并不在于信息没有电子化。
而在于原本已经生成为数据的信息,被转换成供人阅读的文档,然后在对方那一端又被重新转换回数据。
3. 使用 EDI 之后,订购业务会如何变化
使用 EDI 之后,下单方系统中生成的订单数据,会被转换为接单方系统可以读取的格式,直接发送出去。
在接单方,负责人不再需要一边看订单一边录入,而是直接将接收到的数据导入销售管理系统。
flowchart LR
A[下单方的采购系统] --> B[订单数据]
B --> C[通过 EDI 发送・转换]
C --> D[接单方的销售管理系统]
D --> E[接单确认]
D --> F[发货通知]
D --> G[开票数据]
E --> C
F --> C
G --> C
C --> A
下单方向接单方发送订单数据,接单方再向下单方回传接单确认、发货、开票等数据。
关键在于,不需要经过人一边看文件一边转录的环节,数据直接从系统传递到系统。
JIPDEC 将 EDI 解释为一种机制:把各企业专有格式的数据转换为标准格式,接收方同样也会将标准格式转换为自家的格式。
4. EDI 与邮件、PDF、Excel 有什么不同
有时会有人认为「订单已经做成 PDF 用邮件发送了,已经算电子化了」。
确实,这比邮寄纸质文件更快,也更便于保存。但如果接收方仍然是一边看 PDF 一边录入系统,那么录入工作本身其实并没有消失。
整理一下差异,如下表所示:
| 方式 | 发送给对方 | 对方端的处理 | 重新录入 |
|---|---|---|---|
| 纸质・邮寄 | 寄送纸质文件 | 看文件录入 | 需要 |
| 传真 | 以图像形式发送 | 看传真录入 | 需要 |
| PDF 通过邮件发送 | 以电子文档形式发送 | 看 PDF 录入 | 需要 |
| Excel 通过邮件发送 | 发送文件 | 核对内容、加工、导入 | 视方式而定 |
| EDI | 以约定好的数据格式发送 | 系统直接导入 | 原则上不需要 |
JIPDEC 的说明 中,将单据扫描而成的图像,或以普通文字撰写的邮件,与计算机可以再处理的 EDI 数据区分开来。此外,在网页界面上由人手动录入的方式,严格来说也不同于计算机之间的自动交换。
不过,使用 PDF 或 Excel 本身并不是坏事。
重要的是收到的信息之后是如何被处理的。
- 由人看着 PDF 录入
- 打开 Excel 后复制粘贴
- CSV 直接导入系统
- 通过 API 自动登记
即便同样是「电子文件」,后续工作的负担也大不相同。
在判断 EDI 效果时,不能只看发送方式,还要看接收之后人做了什么。
5. EDI 可以交换的信息
EDI 并不只是用于订单的机制。
它可以交换企业间交易中产生的各种信息。
| 业务阶段 | 交换数据示例 |
|---|---|
| 报价 | 报价请求、报价回复 |
| 下单 | 订单、订单变更、订单取消 |
| 接单 | 接单确认、交期回复 |
| 发货 | 发货计划、发货实绩、运单号 |
| 收货・验收 | 收货实绩、验收结果 |
| 开票 | 账单明细、账单更正 |
| 付款 | 付款通知、汇款明细 |
例如,在收到下单数据的那一刻,接单方系统就可以进行如下处理:
- 核对订单编号是否重复
- 核对商品编码是否存在
- 进行库存分配
- 计算交期
- 向仓库发出发货指示
- 向下单方回传接单确认
此外,发货之后还可以根据发货实绩确认销售额,并生成开票数据。
也就是说,EDI 并不只是一个单纯的通信功能。
它以订购业务为入口,成为串联起后续库存、发货、销售、开票的基础。
6. EDI 如何让企业业务更轻松
6.1. 可以减少手动录入与转录
最容易理解的效果就是手动录入的减少。
一边看传真送达的订单,一边录入商品编码、数量、单价、交期的工作将变得不再需要。
减少手动录入后,负责人就可以把时间用在录入以外的异常处理上,例如:
- 库存不足的订单
- 交期异常的订单
- 商品编码尚未登记的订单
- 大额订单
- 需要核对单价或合同条款的订单
不再由人处理所有订单,而是改为常规订单自动处理、只有有问题的订单才由人核对的形式。
6.2. 可以减少录入错误
由人进行的录入工作,总会有一定概率出错。
- 商品编码输错一位
- 数量输成 100 个而不是 10 个
- 送货地点搞混
- 误读期望交期
- 同一订单被重复登记两次
即使使用 EDI,如果原始数据本身有误,问题依然会出现。但由于正确生成的数据不需要在对方端重新录入,因此可以减少因转录而产生的错误。
中小企业厅 也将订购业务数字化的效果列为提升作业效率、减少人为失误、提升交易记录的可检索性。
6.3. 可以加快接单处理速度
在传真或邮件的情况下,接单处理要等到负责人注意到收件、核对内容、完成录入之后才能开始。
订单较多的日子会出现录入排队积压。若负责人休假,处理也可能因此延迟。
在 EDI 中,接收到的数据可以自动导入系统。
在收到订单后,可以立即开始:
- 订单受理
- 库存核对
- 交期计算
- 向仓库发出发货指示
- 回复接单确认
等一系列处理。
接单处理加快,发货所需时间也更容易缩短。JIPDEC 也将 EDI 的效果列为事务作业提速、交付周期缩短、库存压缩等。
6.4. 更容易确认订单状态
当纸质文件、传真、邮件、Excel 混杂在一起时,要查清「那笔订单现在状态如何」需要花费不少时间。
需要依次查看负责人的邮箱、共享文件夹、纸质文件、销售管理系统等。
在 EDI 中,可以以订单编号等为基准,将以下信息关联起来管理:
- 何时收到订单
- 是否已正常导入
- 是否已回复接单确认
- 是否已发货
- 是否已验收
- 是否已开票
- 是否发生过错误或重发
即使收到咨询,也不需要依赖负责人的记忆或个人邮件,而是可以从处理历史中查证。
6.5. 可以对接库存、发货、财务业务
EDI 的效果并不仅限于减少接单负责人的录入工作。
通过将接收到的数据与内部系统对接,后续流程也可以实现自动化。
订单数据
↓
接单登记
↓
库存分配
↓
发货指示
↓
销售登记
↓
生成开票数据
↓
收款核销
反过来说,即使通过 EDI 收到了订单数据,如果仍然是打印出来由人录入销售管理系统,效果就会相当有限。
JIPDEC 也说明,若通过 EDI 收到的数据没有导入企业内部系统,而是打印出来人工处理,那与传真并没有太大差别。
引入 EDI 不仅仅是与交易对象之间的通信对接,接收到的数据要流转到企业内部业务的哪个环节,这一点同样重要。
6.6. 交易数据可以用于经营决策
以纸质文件或 PDF 收到的订单,即使被保存下来,也难以用于汇总分析。
在 EDI 中,交易信息会以结构化数据的形式积累下来。
因此可以进一步连接到以下这类分析:
- 各商品的接单量
- 各交易对象的销售趋势
- 按星期、时段划分的下单倾向
- 交期延误的发生情况
- 缺货较多的商品
- 从下单到发货所需的时间
- 退货或更正较多的交易
JIPDEC 也表示,除了库存分配、生产调度、进出货验收、应收账款登记等日常业务外,EDI 数据还可以用于畅销商品分析、需求预测等。
通过 EDI 建立起可以汇集数据的状态,不仅有助于业务效率化,也是未来实现库存优化与需求预测的前提。
7. 用简单的例子看 EDI 的效果
假设某家批发公司,一天通过传真或邮件收到 100 份订单。
假设将一份订单录入销售管理系统并核对内容,平均需要 3 分钟。
100 份 × 3 分钟 = 300 分钟
也就是说,每天要花费 5 小时用于订单录入与核对。
假设引入 EDI 之后,其中 80 份可以自动导入,剩下 20 份才需要人工核对。
20 份 × 3 分钟 = 60 分钟
虽是简化后的例子,但录入工作从 5 小时变为了 1 小时。
实际上,除此之外,以下这些时间也可能随之减少:
- 辨认难以看清的传真
- 更正录入错误
- 用来核对订单内容的电话
- 查找订单的工作
- 汇总订单清单
- 负责人之间的交接
引入 EDI 的效果,并不仅仅是「节省纸张费用」这类直接成本。
其真正的意义在于,能够减少每天反复发生的细小核对、录入、更正工作。
8. 按部门来看 EDI 的优点
EDI 带来的业务改善,并不仅限于接单部门。
| 部门 | 引入 EDI 前的工作 | 引入 EDI 后可期待的变化 |
|---|---|---|
| 销售・接单 | 看订单内容录入 | 常规订单自动登记,只核对异常情况 |
| 采购 | 制作采购单并寄送 | 从采购系统直接发送 |
| 仓库 | 接收纸质发货指示 | 从接单数据生成发货指示 |
| 财务 | 重新录入账单明细 | 从销售数据生成开票信息 |
| 管理层 | 用 Excel 汇总业绩 | 从积累的交易数据中汇总 |
| 咨询窗口 | 查找邮件或纸质文件 | 按订单编号确认处理状态 |
EDI 能够减少的,不仅仅是单纯的录入工时。
由于信息的所在位置变得清晰,即便不是负责人本人也能方便地确认情况,因此还能减轻业务对特定个人的依赖。
9. 引入 EDI 并不意味着所有工作都能自动化
EDI 是很方便的机制,但仅仅引入并不能让所有工作都自动化。
9.1. 需要与交易对象达成协议
企业之间要交换数据,至少需要确定以下事项:
- 交换哪些信息
- 使用哪种数据格式
- 何时收发
- 订单变更或取消如何处理
- 发生错误时如何应对
- 同一数据重复发送时如何处理
- 在哪个时间点正式确立订单
在 EDI 中,不仅是通信方式,数据项与业务运营规则同样重要。JIPDEC 也整理出需要就通信协议、数据格式、消息项、错误应对、交易基本协议等达成一致。
9.2. 需要统一商品编码等项目
下单方与接单方,有时会对同一商品使用不同的编码。
例如下单方的商品编码是 A-001,接单方则是 100245 这样的情况。
在这种情况下,需要一份用来转换编码的对照表。
除商品编码外,还需要梳理以下项目:
- 交易对象编码
- 送货地点编码
- 单位
- 每包数量
- 税务分类
- 币种
- 日期格式
- 字符编码
即便能够收发数据,只要项目的含义不一致,就无法构成正确的交易。
9.3. 异常处理依然存在
即使常规订单能够自动处理,异常性的交易依然会存在。
- 库存不足
- 已停产商品
- 与平常不同的价格
- 紧急订单
- 订单变更
- 订单取消
- 分批交货
- 退货
- 数据缺陷
重要的是,并不需要勉强将一切都自动化。
将常规处理与异常处理区分开来,常规处理自动化,只把需要判断的部分交给人处理,这样的设计才更现实。
9.4. 会出现与传真、邮件并行的过渡期
并非所有交易对象都能同时切换到 EDI。
因此,在引入初期,有时会出现以下多种接单方式并行的情况:
- EDI
- Web 界面
- CSV 上传
- 邮件
- 传真
- 电话
在这种状态下,即使引入了 EDI,也无法立即减少负责传统业务的人力。
要提升 EDI 的效果,需要从交易量较大的交易对象开始依次迁移,逐步减少人工处理的件数。JIPDEC 也指出,如果仍保留传真或电话等人工处理,就需要相应人员来对应,因此难以充分获得效率化的效果。
10. 适合引入 EDI 的企业
EDI 尤其容易在以下这类企业中见效:
- 每天或每周都与同一交易对象进行订购
- 订单数量或明细数量较多
- 目前是从传真或邮件转录到系统
- 发生过录入错误或重复登记
- 用于确认订单的电话或邮件较多
- 接单之后还会接续库存、发货、开票处理
- 负责人休假时处理就会停滞
- 汇总订单历史或交易状况需要花费较多时间
另一方面,对于一年只交易几次的对象,或订单内容每次都大相径庭的交易,EDI 的建设与运营成本有时可能超过其收益。
是否引入 EDI,不应该只以公司规模来判断。
中小企业厅 也为中小企业建立了用来标准化订购业务的「中小企业通用 EDI」,展示了通过减少专用终端与纸张、将单据以数据形式集中管理,来实现业务效率化的方式。
应该关注的不是员工人数,而是反复发生的录入、核对、转录的工作量。
11. 考虑引入 EDI 时的推进方式
在考虑 EDI 时,并不需要从一开始就选定产品或通信方式。
首先,应先梳理现有业务。
11.1. 将当前的订购方式列成清单
按交易对象,梳理以下信息:
| 确认项 | 内容 |
|---|---|
| 交易对象 | 与哪家公司交易 |
| 订单数量 | 每天・每月有多少笔 |
| 接单方式 | 传真、邮件、Web、CSV 等 |
| 录入去向 | 销售管理、Excel、核心系统等 |
| 录入时间 | 每笔需要多少分钟 |
| 错误情况 | 发生过哪些更正 |
| 后续流程 | 如何对接库存、发货、开票 |
| 异常情况 | 哪些订单需要人工判断 |
完成这一梳理后,就能看出哪些交易对象或业务采用 EDI 化的效果最大。
11.2. 从交易量最大的一家开始
如果一开始就以所有交易对象为目标,需要协调的事项会增多,导入周期也会拉长。
比较现实的做法是,先选择一家符合以下条件的交易对象:
- 交易量较大
- 常规订单较多
- 双方负责人之间沟通顺畅
- 对系统对接有一定理解
- 效果容易衡量
在一家公司确立运营方式之后,再推广到其他交易对象。
11.3. 缩小交换对象范围
一开始并不需要将报价、接单、发货、验收、开票、付款全部纳入范围。
例如,可以先将录入负担最大的订单数据进行 EDI 化。
第一阶段:订单数据
第二阶段:接单确认・交期回复
第三阶段:发货通知
第四阶段:开票数据
通过分阶段扩大对象范围,可以在控制对一线影响的同时确认效果。
11.4. 确认与企业内部系统的对接
即使引入了 EDI 服务,如果无法将数据导入现有的销售管理系统,手动录入的工作仍然会保留下来。
事前应确认以下几点:
- 是否具备 CSV 导入导出功能
- 是否可以使用 API
- 是否能与数据库对接
- 商品编码转换在何处进行
- 如何防止接收数据重复
- 出错时通知谁
- 处理历史保留在何处
在选定产品之前,先确认与现有系统的对接方式是非常重要的一步。
12. 引入 EDI 之后应衡量的指标
引入 EDI 之后,不应止步于「已经可以使用了」,而要确认业务究竟发生了多大变化。
例如,可以对比以下指标在引入前后的变化:
- 接单录入所需的时间
- 处理一笔订单所需的时间
- 录入更正的件数
- 重复登记的件数
- 订单确认的咨询件数
- 发货延误的件数
- 能通过 EDI 处理的订单比例
- 由人核对的异常订单比例
EDI 中重要的并不是能否发送数据。
而是要以手动作业是否真正减少、处理是否变快、错误是否减少来评价。
总结
EDI 是一种机制,让企业之间发生的订单、发货、开票等信息,以计算机可以直接处理的电子数据形式进行交换。
仅仅把传真改成邮件,纸张虽然减少了,但手动录入有时依然存在。
EDI 真正的效果,在于能够将从交易对象收到的数据,直接对接到销售管理、库存、发货、财务等企业内部系统。
通过 EDI 可以期待的主要变化如下:
- 减少一边看订单一边进行的手动录入
- 减少因转录而产生的录入错误
- 加快从接单到发货的处理速度
- 让订单或账单的处理状态更容易确认
- 将库存、发货、销售、开票串联起来
- 将积累的交易数据用于汇总或需求预测
- 减少依赖特定负责人的业务
不过,仅仅签约引入 EDI 服务是不够的。
还需要梳理商品编码等数据,与交易对象约定运营规则,并让数据能够导入现有的企业内部系统。
引入 EDI 的出发点,并不是「使用哪款产品」,而是调查在当前业务中,同样的信息究竟被录入了多少次。
找出在传真、邮件、Excel、Web 界面、销售管理系统之间由人搬运信息的环节,并从中挑选件数多、属于常规化的业务,依次替换为数据对接,这才是切实可行的做法。
致正在考虑订购业务数据对接的您
若想提升企业间订购业务的效率,却不知道该从哪里开始重新审视当前的传真、邮件、Excel 使用方式,首先需要梳理业务的流程。
只要确认交易对象以何种格式提供信息、录入到企业内部的哪个系统、之后又如何对接到库存、发货、开票,就能看清可以自动化的范围。
合同会社小村软件(合同会社小村ソフト)可以为您梳理现状,并就包含现有 Windows 业务应用、CSV・定长文件、数据库、Web 系统等在内的业务对接,提供实现方式的咨询。
我们也能够在不以全面重建为前提的情况下,探讨保留现有架构、仅减少手动录入部分的方案。
相关文章
共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。
什么是数字发票?──与「用邮件发送 PDF 发票」有何不同
数字发票是一种让发票信息从卖方系统直接对接到买方系统、无需人工介入的机制。本文将通俗易懂地解析数字发票与 PDF 发票的区别、它与日本 Invoice 制度的关系、Peppol 与 JP PINT 的运作方式、与电子账簿保存法的关系,以及中小企业该如何入手。
把传真订单迁移到 Web ── 双轨运行期的设计与分阶段迁移实务
介绍将传真订单迁移到 Web 订单或 CSV 导入的实务做法。整理一次性全面 Web 化容易失败的原因、传真与 Web 双轨运行期的设计、商品与客户主数据的整备、CSV 导入这一中间形态,以及如何让客户配合的分阶段迁移步骤。
PowerShell 实用命令合集 —— 积累日常工作中常用的小工具
本文整理 PowerShell 日常工作中常用的实用命令,说明 Measure-Object、Group-Object、Select-String、Compare-Object、Tee-Object、Start-Transcript 等命令的使用场景和时机。
Windows 应用的任务栏托盘常驻与 Toast 通知 —— NotifyIcon 的坑与 AppNotification 的选型
本文整理了将业务 Windows 应用常驻在任务栏托盘(通知区域)并通过 Toast 通知告知用户的实现要点。内容涵盖 NotifyIcon 的正确用法与「关闭后驻留托盘」的设计、资源管理器重启后的重新注册、三种 Toast API(Windows App SDK AppN...
从 WordPress 迁移到 Movable Type ── 正因为是「反方向」,才更需要梳理清楚的实务步骤
从实务角度解说从 WordPress 迁移到 Movable Type(MovableType.net)的步骤。整理迁移合理的场景、文章与固定页面及图片的导入、自定义文章类型的处理方式、通过 URL 设计与 301 重定向延续 SEO 效果,以及插件功能的替代方案。
作者简介
本文作者的个人简介页面。
Go Komura
小村软件有限公司 代表
以 Windows 软件开发、技术咨询与故障排查为中心,擅长难以复现的故障调查,以及既有资产仍在运行的项目。