第6章
电子数据交换

📠 纸质时代的订单

采购员填单 → 打印邮寄或传真 → 对方文员人工录入自己的系统 → 审批、回确认。每一次转手都是一次等待和一次抄错机会：数量、货号、金额错一位，后续核对、退换、索赔的成本远高于录入本身。全程以天到周计。

⚡ EDI 时代的订单

买方 ERP 生成订单数据 → 翻译软件转成标准报文 → 网络直达卖方系统 → 自动解析、自动导入、自动回确认。全程以分钟计，无人碰键盘。自 20 世纪 60 年代诞生至今，EDI 仍是供应链、零售、制造、医疗、金融的底层交易基础设施。

🧾 单证格式化

只处理有固定格式的商业单据；信件、公函等自由文件不在其列。

📏 报文标准化

必须符合国际或行业标准：UN/EDIFACT 与 ANSI X12 为两大主流。

🤖 处理自动化

路径全程由系统走：业务系统→转换→翻译→传输→翻译→业务系统。

🧩 软件结构化

软件由界面、内部系统接口、报文生成处理、格式转换、通信五类模块组成（§6.5 展开）。

⚖️ 运作规范化

报文在商业、法律、审计语境中有记录效力；各国证据规则有别，通常以贸易伙伴协议确认（§6.9）。

🌊 四股推力

• 贸易文件激增：纸张处理成本高、周期长
• 差错率居高：同一数据多系统反复录入，错误、纠纷、延误随之而来
• 周期过长：供货、库存、资金周转全被人工传递拖慢
• 竞争形态转变：客户要更快的响应、更高的准时率、更透明的信息

🪜 五个阶段

• 萌芽期（1960s）：美国航运业在伙伴间传货运信息，无统一标准
• 概念提出期（1970s）：SITPRO 等提出 EDI 概念，大型零售企业先行
• 标准建立期（1970s 末—80s）：TDCC 运输标准；1979 ASC X12；1987 EDIFACT 获 ISO 认可
• 成熟推广期（1990s）：MHS、VAN 与全国贸易平台推动普及
• 互联网演进期（21 世纪—）：Web-EDI、XML/EDI、AS2、API 补充传统 EDI

🏭 行业应用模式

由主管部门、行业协会或龙头企业牵头，统一报文格式、业务流程与节点职责。代表：海关 EDI 通关系统（电子报关单、放行通知、税单在海关—企业—物流间自动交换）；国际集装箱运输 EDI 示范工程（船公司、货代、港口、堆场、车队、海关互联，订舱到放行全程信息同步）。优势：标准集中、协同度高，适合行业内大规模重复交易。

🎡 EDI 中心模式

区域性 EDI 服务中心作枢纽，集中提供标准转换、报文处理、通信接入、节点管理与业务监控：企业只接中心一处，不必与每个伙伴分别建链。代表：广东 EDI 中心、上海港航 EDI 中心。优势：降接入门槛、提覆盖率、统一标准版本与服务质量，适合区域与产业链协同。

💰 成本层

省打印、装订、邮寄、归档的人力与场地；更省差错的善后成本——录错一位的核对、退换、索赔远贵于录入本身。

⏱️ 节奏层

下单、确认、发货、开票、付款的每步等待被压缩：周期从几天到几分钟—几小时，现金流随之顺畅；JIT、VMI 等协同模式离开它几乎无法按现实节奏运转。

🎫 准入层

大型零售商与制造商常把 EDI 收发能力设为供应商硬门槛：产品与价格再好，没有 EDI 也进不了核心供应链。

📏 EDI 标准（语言规则）

规定商业文档的表示规则，让不同企业、不同平台能准确互懂。合格标准四要求：语义无歧义、平台无关、应用无关、通信方式无关。

🔄 EDI 软件（转换工具）

做内部格式与标准格式的双向转换：映射软件＋翻译软件＋通信软件三件套（§6.5 逐件拆）。

🛣️ 通信网络（传输通道）

报文的邮路：点对点直连、VAN 增值网、互联网三选（第 11、12 页）。

🔌 点对点直连

与每个伙伴建专属连接、各自维护参数。直接、可控、时效强；但伙伴一多，连接数与参数维护膨胀。适合交易量大、伙伴少、IT 强的企业。

📮 增值网络 VAN

第三方“电子邮局”：发方投递到对方电子邮箱，收方按自己节奏取件。服务含存储转发、多伙伴统一接入、协议转换、审计通知、安全备份；按字符/千字节计费（或连接时间/月费），跨 VAN 需互联协议。

🌐 互联网直连

FTP/SFTP/FTPS/AS2/HTTP(S) 在公网交换。投入与运营费最低、增长最快；代价是加密、回执、监控等安全机制要自己配齐，不能像 VAN 那样外包。

🏛️ 出身与信封

由 ANSI 认可的 ASC X12 委员会制定（1979 年特许），结构吸收了运输业 TDCC 等早期标准。三层信封：ISA/IEA 交换层（收发方与控制号）→ GS/GE 功能组层（同类事务集打包）→ ST/SE 事务集层（一份具体文档）。

🔢 读法：代码即文档类型

每种文档一个三位数字代码——供应链日常里最高频的一组见右表；其中 856（ASN 发货通知） 与 997（功能确认） 是物流人最该先记住的两个。

🌍 出身与文档体系

联合国制定，1987 年语法获 ISO 认可为 ISO 9735——与 X12 最大的身份差异。配套一整套目录：数据元目录（EDED）、复合数据元目录（EDCD）、代码表（EDCL）、段目录（EDSD）、标准报文（UNSM）及设计指南。

🪜 层级（自下而上）

数据元 → 数据段 → 报文 → 功能组 → 交换；信封写法：UNB（UNG）UNH … UNT（UNE）UNZ——下一节逐字读真报文。

🔤 数据元（最小单位）

简单数据元：一个日期、一笔金额、一个数量；复合数据元：多个成分组合，如 1:USD:4。每个数据元都有编号、名称、格式、长度与必选/条件属性。

🧱 数据段（标识符＋数据元列）

DTM+137:20260311:102'

DTM 是段标识符（日期/时间段）；137 是限定符（说明这是哪种日期）；20260311 是日期值；102 是格式代码（YYYYMMDD）。

🔁 循环（段组）

表达一对多：发票的多个行项目、发货通知的多个货箱，都靠重复同类段组来写。报文（事务集）则是头段＋主体段＋尾段组成的完整文档容器。

🗂️ 它干的五件事

• 定义内部字段与平面文件字段的对应关系
• 数据格式转换（如日期 YYYY/MM/DD ↔ YYYYMMDD）
• 代码转换（自家商品码 ↔ GTIN、自家单位 ↔ 标准代码）
• 必要的数学计算（金额汇总、税率换算）
• 条件逻辑（某字段有值才输出某段）——且收发双向都要设

🎯 存在的理由

若没有映射层，每新增一个贸易伙伴、每改一次内部系统，就要重写一套接口程序。映射把对应关系配置化：伙伴再多，维护的是一张对应表，而不是一堆定制代码。

⚖️ 四项本职

• 按标准语法把平面文件生成标准报文，或把报文解析回平面文件
• 校验数据元的格式与长度
• 检查必填字段与业务规则
• 信封的自动生成与解析（控制号、段数都由它管）

🔗 与映射的分工纪律

数据库原始数据先经映射成平面文件、再交翻译——不许跳步直连。分层使映射逻辑与翻译逻辑低耦合：换标准只动翻译，改内部系统只动映射。

📬 通信软件的职责

• 维护伙伴标识与通信地址
• 自动发送与接收报文
• 管理传输日志、MDN 回执与功能确认
• 异常时自动重传或告警

🔌 与内部系统的四种集成

• 文件轮询：最简单，适合批量场景
• 数据库直连：实时性高，但要严控访问权限
• API / Web Service：适配云 ERP 与现代架构
• 消息队列 / ESB：解耦系统依赖，大型企业集成平台之选

😖 传统语法的四道门槛

• 封闭：EDIFACT/X12 只能靠专用翻译软件读写，开发调试被少数厂商工具绑定
• 门槛高：中小伙伴搭建成本高、望而却步
• 学习曲线陡，标准修订与扩展周期长
• 与 Web 技术栈集成不顺畅

✨ XML 的五副面孔

自描述、层次清晰、平台无关、可扩展、支持标准化校验——几乎所有语言与工具都能原生解析。同一张订单对照看（右记）：EDIFACT 要靠限定符猜语义，XML 标签自带含义，不懂 EDI 的人也能读个八九不离十。

🧭 做法

某国际货运代理同时对接多家航运公司的 EDIFACT 系统与多个客户的 XML 接口：内部数据统一为 XML 一份，经 XSLT 转成 EDIFACT 的 IFTMIN/IFTMAN 报文，再以 AS2 安全传输（下一节主角）。

📉 效果与边界

原本分散重复的格式适配被集中到一条转换链：新增伙伴的对接周期明显缩短。缩短多少取决于原系统结构与接口复杂度——教材特意留了这句分寸，工程汇报也当如此。

💸 贵：按量计费

80—90 年代 VAN 靠 X.400/MHS 与专线/拨号提供可控可审计的交换，自有其合理性；但按流量/时长计费意味着业务越大、邮费涨得越快。

🧱 隔：互联不统一

各 VAN 的协议、信箱格式、互联规则互不一致：对接不同 VAN 的伙伴要另签互联协议、另付转接费。

🕸️ 旧：与新世界脱节

X.400 在公共互联网部署复杂，没给 Web 应用与云平台留接口。90 年代中后期，产业界要找一条“保留 VAN 级安全、花互联网的钱”的新路——AS2 应运而生。

📜 出身

由 EDI 厂商联合体 Drummond Group 牵头制定，2005 年 IETF 发布为 RFC 4130。设计极简：HTTP/HTTPS 本已成熟廉价、无处不在，只需在其上叠加 S/MIME 的加密、签名与回执，即可平替 VAN 的安全保障。

🏬 沃尔玛迁移令

21 世纪初，沃尔玛要求数千家供应商限期把 EDI 传输从 VAN 迁到 AS2，逾期影响订单与结算。对沃尔玛：VAN 按流量计费是天文数字，AS2 走公网边际成本近乎为零，MDN 回执又满足其海量报文的实时追踪与审计。

🧾 它是什么

MDN（报文处置通知）由接收方用自己的私钥签名后回传。发送方据此可证明：对方确实收到了这份报文，且内容与发出时完全一致（回执含原文 MIC 校验值）——这是 AS2 不可否认性的技术基础。

🔀 同步 vs 异步

• 同步 MDN：在同一个 HTTP 连接里直接返回，快、简单
• 异步 MDN：接收方处理完后另行发送，适合大报文或慢处理
• 两种 MDN 都应妥善保存归档，作为传输完成与不可否认的证据（§6.9 运维要查“迟迟未回的 MDN”）

🚗🏦 行业专用协议

• OFTP/OFTP2（ODETTE）：欧洲汽车业广泛使用，OFTP2 支持互联网传输、加密、证书、压缩与大文件
• EBICS：德、法企业与银行间的金融报文传输，同样基于 HTTP＋签名＋不可否认

🌐 Web-EDI：过渡形态

大买家建门户，小供应商登录填表单，后台自动转标准报文。免装软件、接入快；但人工录入比例高、量大即低效，定位是小供应商进入 EDI 体系的过渡方案，不是终点。

🏭 JIT 准时制生产

• 制造商以 830 / DELFOR 向供应商共享生产计划
• 以 862 / DELJIT 发精确到窗口的发货指令
• 供应商以 856 / DESADV 回发货通知、安排到货时间

三段报文接力，生产线才敢零库存等料。

📦 VMI 供应商管理库存

下游把库存与销售数据持续共享给供应商，供应商据此主动补货——把补货决策权连同数据一起交给更懂产品的一方，换缺货与积压双降。

🎫 供应商四件套

零售商的常见要求：收 850 订单、回 855 确认、发 856（ASN）、开 810 发票，每份报文回 997 功能确认。缺一环，订单与结算都可能卡住。

📋 一份合格的 ASN

须含商品明细、包装层级、SSCC 条码（第 2 章）、承运人信息、预计到货时间——配送中心据此提前排收货计划，而不是货到门口才临时调度。

🔗 为什么汽车离不开 EDI

供应链是深的多级链：主机厂（OEM）→ 一级 → 二级 → 更深层供应商。JIT 与精益生产要求报文在这条长链上顺畅接力，任何一级断档，整条产线停摆——汽车用 EDI 已四十多年，是最“刚需”的行业。

🗺️ 地域三分

• 欧洲：OFTP/OFTP2 协议＋ODETTE 文档
• 德国：VDA 消息格式
• 北美：基于 X12 的 AIAG 规范
• 区域专网：ANX（北美）、ENX（欧洲）、JNX（日本）

🏦 金融服务

付款、应收应付、现金管理、证券交易。协议面孔多：FTP、FTPS、AS2、OFTP、EBICS、FIX；格式：ISO 20022、NACHA、BAI2、SWIFT、ISO 15022——SWIFT 在第 15 页已露过面，它本质上是银行间的“EDI 专用网”。

🛃 海关与国家贸易平台

CUSDEC（申报）/ CUSRES（回执） 承担电子报关核心功能。更进一步：一些国家把海关、港务、政府许可整合进全国单一贸易平台——新加坡 TradeNet 是较早且成熟的案例（呼应第 6 页我国的行业应用模式）。

📜 TPA 要写清的九件事

• 双方 EDI 标识符；报文类型与版本要求
• 通信协议及 URL、端口、证书信息
• 加密与签名等安全要求
• 测试程序与验收标准；电子报文的法律效力
• 数据归档期限与访问要求
• 错误、欺诈、赔偿的争议解决；配置变更的提前通知时限

经 VAN 接入的，还要另审 VAN 服务协议（服务范围、责任、安全、保存期限、终止条件）。

🧪 四级测试才准上线

逐步验证报文能被正确生成、传输与解析，四级全过才切换生产环境。

🔐 三件套

• 加密：防未授权读取
• 数字签名：验身份、保完整
• MDN / 功能确认：送达证据

🗝️ 密钥全生命周期

生成、存储、交换、归档、销毁——每一环都要有规程；证书过期是 EDI 事故的头号常见原因（下一页运维清单里有它的位置）。

🎫 公钥真伪

靠 CA 与 X.509 证书目录验证（第 4 章信任链回收）：签名再完美，公钥是假的也全盘皆输。

📡 监控与告警

实时监控传输状态，异常及时告警——EDI 是无人值守系统，沉默不等于正常。

🧾 回执巡检

专查迟迟未收到 MDN 或功能确认的报文：那是交易悬空的信号，要主动追踪闭环。

🗄️ 归档与审计

报文完整归档、定期审计——既为争议举证，也为合规检查。

📌 版本台账

维护标准版本与每个伙伴的版本台账：伙伴升级 D01B 而你还停在 D96A，报文就会鸡同鸭讲。

🎫 证书与参数

跟踪证书有效期与通信参数变更——到期前换证是运维日历上的固定事项。

🤝 伙伴响应

及时响应伙伴的查询与问题：EDI 是双方的系统，一方掉线，两方停摆。

📌 本章带走的六件事

• EDI 的本质是机器对机器：接收者是系统不是人——与邮件、条码的判据在此
• 系统三支柱：标准定语言、软件做翻译、网络管邮路；标准不管传输
• 两大标准双轨并行：X12 数字代码行北美，EDIFACT 字母代码行欧亚与国际贸易
• 报文逐级组织：数据元→段→报文→交换；信封管身份、唯一、校验与审计
• 软件两道工序：映射管自家格式，翻译管标准语法；集成深度决定收益真假
• AS2 以“签名＋加密＋签名 MDN”在公网上复刻了 VAN 的安全，还近乎免费

✍️ 课后思考

• 习题 2：为什么刷卡与扫码不算标准 EDI？用第 4 页的判据回答
• 习题 3：把第 10 页的订单链画成流程图，标出三种软件的位置
• 习题 6：选 JIT 或 VMI 写一段分析——先想“哪一步靠人工就转不动”