简介：MES 接口设计说明书面向 SAP R/3 与制造执行系统（MES）集成项目的设计、开发及实施人员，聚焦 MELEBUS-BMAS 模板下系统间接口雏型的搭建与验证。日文原版文档围绕制造指图抽取、实绩数据计上两条主链路，说明系统化对象范围、适用前提、R/3 侧与 MES 侧接口分工、排他控制及预想业务流，并给出接口文件一览与规格、程序规格、参数设定等内容，便于读者厘清接口边界、字段组织与批处理运行方式。资源包仅含 1 个 doc 文件，大小约 178KB，章节层次完整，适合按模块查阅。已有 2668 人学习，可作为 MES 接口方案设计、开发对照与项目交接的参考底稿。
1. 需求先立住：为什么车间和 ERP 之间必须有一份 MES 接口设计说明书
很多制造执行系统（MES）项目真正卡住的地方，是 ERP 和车间之间的那层文件约定没有讲清楚，并非 MES 本身。ERP 里排好的制造指图要下达到产线，产线做完了要把投入和完好的数量回传——这两件事只要差一个字段含义、一个换行符，整个班的产出就统计不上。我见过太多团队把这块当成“接口联调再说”，结果上线第一周天天靠手工补单。
这套方案解决的正是这件事：给出一份完整的 MES 接口设计说明书，把 ERP 侧（本文以 SAP R/3 模板为背景，逻辑通用于其他 ERP）与 MES 之间的制造成指图抽取、实绩数据计上两条链路，从系统范围、前置条件、文件规格、程序规格到参数配置全部定义清楚。适合谁？做 ERP-MES 集成毕设的学生、要给车间写交付物文档的工程师，以及需要评审别人接口设计是否站得住的技术负责人。它是一份可以直接套结构、套字段、套验收口径的说明书雏形，并非概念介绍。
2. 总体架构与边界划分：四类文件、两个系统、一条排他线
2.1 系统化对象的边界先切干净
做接口设计最容易犯的错是边界模糊：到底哪些功能算在这个接口里？这份说明书在开头就把范围收死，只包含 ERP 侧的两个功能——制造成指图数据抽取处理、实绩数据计上处理。MES 侧的接口功能不在本接口范围之内，只作为对端假设描述。这个划分很关键，因为它直接决定了后面文档的责任归属：哪些异常由 ERP 侧兜底，哪些必须由 MES 侧自己保证。
边界之外还有三层前提条件，我通常会在方案评审时逐条确认。第一是范围限制在单一工厂内 ERP 与 MES 的连携，适用的生产方式是“会发制造成指图”的那种，程序以批处理方式运行、每天跑一到两回。第二是操作系统环境，双方都限定在 Windows 与 Unix 两类，MES 侧独立于 ERP 控制操作。第三是网络与文件，接口文件通过文件共享让两侧处理都能访问到同一个文件——这一点是全部排他机制的地基，没有共享目录，后面的管理文件方案无从谈起。
2.2 数据流与四类接口文件
整套接口围绕四类文件运转，两条业务链各两个：
| 文件类别 | 生成方 | 消费方 | 内容要点 |
|---|---|---|---|
| 制造成指图数据文件 | ERP | MES | 指图头信息，含指图号、品目、数量、指图类型、着手日 |
| 构成数据文件 | ERP | MES | 指图对应的品目构成明细 |
| 投入实绩文件 | MES | ERP | 构成员投入的品目代码与数量 |
| 完成实绩文件 | MES | ERP | 完好数量、不良数量、预计完了日 |
文件一律是 Windows 或 Unix 格式的文本文件，换行码和逻辑路径都由变式（variant）指定，不在程序里写死。接口不做代码转换，数据以透过方式原样传给对方——这条约束看着不起眼，实际是后面一堆“乱码、数量错位”问题的根源，所以编码约定必须在联调前白纸黑字写进说明书。
2.3 排他控制：一个管理文件解决跨系统互斥
ERP 和 MES 是两个独立系统，靠同一个共享目录交换文件，谁都不能保证对方此刻不在写。这份方案的解法非常朴素：设置指图处理和实绩处理两个管理文件，某一方处理中就先创建管理文件，另一方只在“管理文件不存在”时才执行；处理完成即删除管理文件。写入侧永远以追加模式往接口文件里加记录，删除动作只由读取侧在处理完成后做。
配套的还有唯一键机制：每个接口文件都带唯一键，读取侧收到数据时按主键判断是否为重送，重送的直接跳过不处理。已处理完成的交易不支持反向修改接口，要改就各系统走手工。这套机制的适用前提是“单工厂、低频批处理”，如果你面对的是高频实时场景，文件轮询会撑不住，那就该换成消息中间件——但作为课设或中小工厂原型，这个方案足够稳，也好讲清楚。
3. 指图抽取链路的实现：抽取条件、变式与程序结构
3.1 抽取条件必须逐条落成可判定规则
指图抽取是整个接口的第一棒，抽错一条下游全歪。说明书里给了两条硬条件加一组选择条件，我整理成下面这张判定表，写文档的时候建议照这个粒度写，不要用“已发指图”这种含糊说法：
| 维度 | 判定规则 |
|---|---|
| 日期 | 着手日落在参数文件指定的日期范围内 |
| 系统状态 | 已发指图，且未完了、未部分完了 |
| 有效性 | 未被取消的有效指图 |
| 发送管理（可选一） | 送信日志文件中不存在、即 ERP 侧未送过的指图 |
| 用户状态（可选二） | 指图用户状态 SEND 标记未 ON |
这里有个设计上的亮点值得单独讲：指图抽取的管理方式做成二选一。方式一是用送信日志文件做重复检查，方式二是用指图用户状态里的 SEND 标记。前者不改动业务数据，靠外部日志判断；后者把“已发送”写回 ERP 的业务对象上，状态更直观，但会污染业务数据。两种方式的取舍我在方案里通常会这样建议：原型验证阶段用日志文件，改动小、回滚容易；正式运用选用户状态，因为运维人员查指图状态时一眼能看到发没发，少一堆排查成本。
3.2 程序结构与伪代码骨架
抽取程序（说明书里以 ZMAF001 这个程序名举例）采用结构化写法，可读性优先。核心逻辑用伪代码表达大致是：
FUNCTION ZMAF001_ORDER_EXTRACT. " 1. 读取参数文件：日期范围、变式名、抽取方式、逻辑路径、换行码 READ_PARAM_FILE -> ls_param. " 2. 依据变式确定抽取条件（日志方式 / 用户状态方式） CASE ls_param-mode. WHEN 'LOG'. " 送信日志文件中不存在 SELECT 指图 FROM 指图表 WHERE 着手日 IN ls_param-date_range AND 系统状态 = '已发' AND 未完了 AND 未取消 AND NOT EXISTS ( 送信日志 ). WHEN 'STATUS'. " 用户状态 SEND 未 ON SELECT 指图 FROM 指图表 WHERE ... AND 用户状态 <> 'SEND'. ENDCASE. " 3. 排他检查：管理文件存在则直接退出，不输出 IF 管理文件存在. WRITE_LOG '对方处理中，跳过'. RETURN. ENDIF. CREATE 管理文件. " 4. 追加写出头数据与构成数据，文件不存在则新建 APPEND 指图头 -> 指图数据文件. APPEND 构成明细 -> 构成数据文件. " 5. 处理成功后回写发送标记（状态方式）或送信日志（日志方式） " 6. 输出开始/结束文件与记录级日志，删除管理文件 ENDFUNCTION.代码里的几个点值得展开说。第一，排他检查必须在抽取之前做，且管理文件的创建要放在实际写文件之前，否则两个程序同时跑的时候看似互斥实则已经越过去了。第二，文件写入用追加模式，说明书明确写了“文件存在就追加，不存在则新建”，这样一天多批也不会互相覆盖。第三，回写发送标记的时机是“正常完了之后”，不能边写边标，否则中途失败会丢单。参数文件的字段建议至少包含：日期范围（前后天数）、抽取方式、指图数据与构成数据的逻辑路径、换行码（CRLF 或 LF）、日志保留天数——这几项在变式里可配，换环境时不用改代码，这是这份设计里最实用的一条。
3.3 日志与事后追溯
日志分两类，我强烈建议所有接口方案都照这个二分法设计：开始/结束文件记录每次运行的整体结果，一眼看出今天跑没跑、成没成；日志文件按记录粒度记，哪张指图写了、哪张跳过了、什么原因。接口出问题时，最先看的就是这两类日志，比翻数据库快得多。日志保留期限放进变式，别硬编码。
4. 实绩回传链路的实现：数据校验、二重计上防护与类型选择
4.1 MES 侧输出的约定
实绩链路方向反过来，MES 是产出方。约定是 MES 按制造成指图单位、每天汇总结算投入实绩与完成实绩，写入接口文件；如果 MES 内部拆分了制作指示书，先在 MES 侧按一张指图汇总好再输出，ERP 侧只认指图单位的实绩。完成数据上 MES 要打上“部分确认/最终确认”的区分标记，ERP 靠这个判断指图是否完了。排他同样用实绩处理管理文件控制。
4.2 ERP 侧的计上处理与防护逻辑
ERP 侧收到文件后的处理顺序是这份方案里最需要照抄的部分：
FUNCTION ZMAF005_ACTUAL_POST. " 1. 处理济检查：按唯一键剔除已处理记录（防重送） " 2. 排他检查，创建实绩处理管理文件 " 3. 先落工作数据库（work table），不做直接计上 INSERT INTO zw_actual_work ... FROM 接口文件. " 4. 逐条校验后计上 LOOP AT 工作数据. " 4.1 背冲品目（backflush）的投入实绩 -> 报错写日志，不自动计上 IF 品目-背冲标记 = 'X' AND 记录类型 = '投入'. WRITE_LOG '背冲品目不可计上'. CONTINUE. ENDIF. " 4.2 构成品目必须在指图发行时点的 BOM 内，否则报错 IF NOT EXISTS ( BOM 中该品目 ). WRITE_LOG 'BOM 外品目'. CONTINUE. ENDIF. " 4.3 按变式选择的实绩类型计上：累计实绩 或 作业日别实绩 CASE ls_param-actual_type. WHEN 'CUMULATIVE'. 计上累计实绩. WHEN 'DAILY'. 计上作业日别实绩. ENDCASE. ENDLOOP. " 5. 全部完成后删除接口文件、输出两类日志、删除管理文件 ENDFUNCTION.关键设计点有三个。第一，先落工作库再计上，这是防二重计上的后悔药：处理中途异常终止，重启后靠处理济检查加工作库状态判断，不会重复往指图上加数。第二，背冲品目的投入实绩直接报错而非静默处理，因为背冲是 ERP 自动倒冲的逻辑，MES 再报一次会打乱库存；要改背冲数量走 ERP 的作业确认界面手工改。第三，实绩类型做成变式选项——MES 可能回传累计实绩，也可能回传按日实绩，两种口径的计上方式不同，选型必须在运行参数里定死，不能靠程序猜。
4.3 变更与取消为什么要挡在接口外
方案明确不支持通过接口修改或取消已计上的实绩。原因不难理解：接口是批量的、无事务上下文的，一条修改记录进来，ERP 侧很难确定它对应哪一次计上、以什么顺序生效。所以约定是接口只管“增量计上”，计上之后的修正一律走 ERP 手工。这条边界写进说明书，验收时就有了扯皮的依据——不是接口做得不全，是设计上有意不接。
5. 避坑与常见问题：联调阶段最容易翻车的五个点
5.1 文件能读到但数据对不上——换行码与编码
现象是 MES 侧打开文件一切正常，但 ERP 读进来数量错位、末尾多出乱字符。原因基本是两个：换行码不匹配（Windows 侧 CRLF，Unix 侧 LF），或者文件被某一环节做了代码转换。这份设计里换行码是变式配置项，联调第一步就该把两侧环境的换行码对齐。解决方式是把“不转换代码、透过传递”写进接口约定，任何中间环节加转换都要在方案评审时被拦下。
5.2 同一条指图被重复计上
现象是同一批实绩在指图上翻倍。原因通常是处理济检查失效：要么唯一键在 MES 侧生成时重复了，要么程序异常中断后接口文件没删干净又跑了一遍。解决靠两道锁——读取侧按唯一键判重送，计上前先落工作库，异常重启时先查工作库状态。我在方案里会把“工作库表结构 + 清理策略”作为必写章节，不留给开发临场发挥。
5.3 排他失效导致文件写坏
现象是接口文件出现半行记录或内容错乱。原因多为管理文件的判断与创建之间有间隙，或者某一侧程序崩溃后管理文件残留，导致对方永远判定“处理中”而不干活。解决是把管理文件的生命周期写死：创建紧跟判定、完成必删、异常退出要有清理入口。运维上再补一条巡检，管理文件存在超过一定时长就告警。
5.4 指图在 ERP 侧被改了，MES 侧不知道
现象是车间按旧指图生产，ERP 里指图已变更。这份方案的设计前提是：抽取之后指图原则上不在 ERP 侧修改，变更、分割、现品票发行都由 MES 侧管理。如果实际业务做不到，就必须在方案里补一条“变更后重新抽取”的规则，否则一定出问题。这条在需求评审阶段就要和业务方确认，别等到上线才发现。
5.5 指图类型没用来区分特急和修返
现象是特急指图和修返指图混在正常队列里，排产看不出优先级。方案里建议用指图类型通知 MES 侧，特急、修返各自单独设类型。这不是技术问题而是建模问题，但一旦漏了，后面想补就得改两侧的数据结构。我的习惯是在指图主数据设计阶段就把类型编码表定下来，随接口文档一起交付。
6. 验收与答辩：用一张对照表把设计讲透
接口设计这种文档类交付物，答辩时最怕讲成“我写了哪些章节”。评委想听的是：你的设计能挡住哪些真实故障。我一般会准备一张验收对照表，左边是方案里的设计决策，右边是对应的故障场景和验证方法，现场按这张表过一遍，比念目录有说服力得多：
| 设计决策 | 挡住的故障 | 验证方法 |
|---|---|---|
| 换行码、路径变式化 | 跨平台环境文件读错 | 在两套环境各跑一次，比对解析结果 |
| 唯一键判重送 | 重送导致重复计上 | 手工重放同一接口文件，确认被跳过 |
| 工作库先落再计上 | 中途异常二重计上 | 计上过程中强杀进程，重启后核对数量 |
| 管理文件互斥 | 双方同时读写文件损坏 | 两侧同时触发，观察是否有一侧直接退出 |
| 背冲品目报错不静默 | 库存被重复倒冲 | 造一条背冲投入实绩，确认进错误日志 |
| 实绩类型变式选择 | 累计与日别口径混用 | 切换变式各跑一批，核对指图实绩 |
答辩陈述建议按“边界—文件—程序—异常”四段走：先讲清接口包含哪两个功能、不包含什么，这体现你对范围的掌控；再讲四类接口文件的字段与生成消费关系；然后挑抽取程序或计上程序其中一个，把排他、判重、日志三件事讲细；最后主动抛出你预判的失败场景和防护设计。评委最爱追问的通常是“重复数据怎么办”“一方崩了怎么办”“指图改了怎么办”，这三问对应上面的判重、工作库和管理文件，提前准备好就能接住。
还有一个很实用的技巧：把参数文件当成答辩道具。现场展示变式里日期范围、抽取方式、换行码、日志保留期这几项，说明换环境、换策略时不用改代码，这能直观体现设计的可维护性，比讲十句“结构清晰”都管用。
这份说明书我前后改过几版，血泪经验是：接口文档里凡是写“原则上”“通常”的地方，联调时都会变成争议点，所以每一条约定都要落到可判定的规则上——要么有字段，要么有校验，要么有日志。从那以后我每次写接口方案，都会强制走一遍“每条约定能不能被一条测试用例验证”的自检，验不了的当场改写成可判定规则。希望这套结构帮到你，照着填自己项目的字段和流程，就能交出一份经得起追问的接口设计说明书。
本文还有配套的精品资源，点击获取
