ERP与MES接口设计：边界约定、幂等与排他实践

简介：《MES 接口设计说明书》面向 SAP R/3 与制造执行系统（MES）对接的实施人员与开发工程师，围绕 MELEBUS-BMAS 模板下的接口附加程序，说明制造指示数据抽取与实绩数据计上这两类跨系统集成如何实现。文档先介绍系统概要、适用前提与假定业务流程图，再给出接口文件一览与文件格式定义，并分别展开制造指示抽取、实绩计上以及 R/3 与 MES 间排他控制（同步处理）的处理概要；后半部分对 ZMAF001、ZMAF005 两段程序及参数设定逐项说明，其中运行环境变体化（换行符、文件逻辑路径、日志保留期限）与指示抽取管理方式的可选设计尤具参考价值。压缩包内含 1 个 doc 文件，约 178KB，体量轻便、结构完整。目前已有 2668 人学习，适合用作接口原型搭建与规格梳理的对照材料。

1. 从一份二十年前的接口说明书说起：MES 接口真正难的是边界而不是传输

有个朋友接手一个老车间的对接活儿，两边系统中间没消息队列，也没 API 网关，就一个共享目录，双方往里面丢竖线分隔的文本文件。他第一反应是“这也太原始了”，结果翻到一份 2002 年底成文的 MES 接口设计说明书，看完就不吭声了：抽取条件怎么卡、谁负责删文件、重复记录怎么识别、处理崩了怎么不二重计上，全写死了。这份说明书讲的是 ERP 侧模板与制造执行系统之间的两段追加程序——制造指图抽出和实绩数据计上，配套接口文件规格、程序规格和参数设定。它适合两类人：正在做 MES 接口对接、需要一份能直接照着写方案的开发者，以及要写接口文档但不知道边界该怎么划的人。传输方式会过时，边界约定不会。

2. 架构拆解：R/3、MES 与共享文件区的三段接力怎么分工

这套接口最容易被误解成“从 ERP 导个文件给车间”。实际是两条方向相反、各自独立的流水线，中间靠一个共享文件区碰头，谁写谁读谁删都有明确归属。理解这一点，后面所有程序细节才有落脚点。

2.1 四类业务文件、两类管理文件和一份日志

先把文件盘清楚。业务文件按方向分两组：ERP 往下发的指图数据和指图构成数据，MES 往上交的投入实绩和完了实绩。管理文件是两把锁：指图处理管理文件、实绩处理管理文件，分别守两条流水线。日志则分两种——开始/终了文件记录一次作业的起止和总体结果，记录级日志按行记处理明细，出问题先看前者定位批次、再看后者定位到具体指图号。

注意“删除方”这一列。这是整套设计里最容易被新人改坏的地方：写的一方永远只追加，读的一方处理成功后才删。如果两边都想着“我写完顺手清一下”，文件会在对方读到一半时消失，那种故障排查起来非常难受。

还有一条隐含约束写在前提条件里：接口文件不做代码转换，原样透传。也就是说字符集、改行码这些问题不会在程序里被兜底，只能靠双方约定一致。这一点后面会单独说，它是实际项目里最容易翻车的地方之一。

2.2 说明书自己的章节骨架，就是一份可复用的文档模板

这份说明书目录排得很克制，五章：系统规格、文件接口规格、程序规格（ZMAF001）、程序规格（ZMAF005）、参数设定。映射到实际工程目录，大致是这么个结构：

mes-interface/ ├── 01_system_spec/ # 系统规格：目的、范围、前提条件、业务流 │ ├── overview.md # 系统化对象范围、注意事项 │ ├── precondition.md # 单工厂、生产方式、批处理频度、OS/网络前提 │ └── exclusion.md # R/3 与 MES 之间的排他控制说明 ├── 02_file_spec/ # 文件接口规格 │ ├── file_list.md # 接口文件一览（方向、键、删除方） │ └── file_layout.md # 每个文件的字段定义与长度 ├── 03_program_zmaf001/ # 指图抽出程序规格 │ ├── spec.md # 抽取条件、输出、日志、排他、后处理 │ └── variant.md # 选择画面与变式说明 ├── 04_program_zmaf005/ # 实绩计上程序规格 │ ├── spec.md # 取入、校验、登录、日志、排他 │ └── error_list.md # 业务错误码与处置 └── 05_parameter/ # 参数设定 ├── env.ini # 改行码、逻辑路径、日志保存期限 └── extract.ini # 抽取日数范围、抽取管理模式

这么排不是洁癖。文件规格和程序规格分开，是因为前者是双方签字的契约，后者只是我方实现；契约变更要走双方确认，实现变更自己改就行。把两者混在一份文档里，半年后没人说得清哪段是承诺、哪段是细节。

再看业务边界，说明书里有一句很关键的话：指图发行之后的重发行、再印刷、变更、移动单位分割、现品票发行打印，都由 MES 侧管理，ERP 侧基本不再改。反过来，实绩一旦计上到 ERP，数量要改也只能在 ERP 侧改，不提供从 MES 反向修改或取消的接口。这就是主控权划分——一份数据在同一时刻只有一个系统说了算，另一个系统只读。很多对接项目做成两头都能改，最后数据对不上，谁也说不出是哪边改坏的。

2.3 两段程序的分工与执行时序

ZMAF001 负责往下走：按条件捞指图头和构成品目，追加写文件，写日志，正常结束后把捞出来的指图打个用户状态标记，表示“已发过了”。ZMAF005 负责往上收：读 MES 交上来的实绩文件，逐行校验，落到工作区表，再调确认相关功能把实绩记到指图上，成功才删文件。

两边都以批处理方式跑，一天一到两轮。这个频度决定了后面很多取舍：不需要秒级锁，不需要事务级并发控制，文件锁加唯一键就够；但也意味着一旦某一轮失败，问题要等到下一轮甚至第二天才暴露，所以日志的完整度比性能重要得多。

提示：把“批处理频度”写进前提条件不是废话。频度一改，排他方案、日志保留期限、甚至文件切分策略都得跟着改。

3. 指图抽出接口 ZMAF001：抽取条件、文件追加与 SEND 回写的完整链路

这一段是整份说明书里信息密度最高的部分。它要回答三个问题：捞哪些指图、怎么写出去、怎么保证下一轮不重复捞。

3.1 抽取条件：日期范围、系统状态、取消标记，外加一个二选一的管理模式

抽取的硬条件是四条叠加：着手日落在参数文件指定的日期区间内、系统状态为已发行且未完了或部分完了、指图未被取消、工厂在范围内。第四条是“只处理一个工厂”，这来自前提条件里“限定单一工厂内 ERP 与 MES 的连携”。

真正需要设计决策的是第五条——怎么判断“这条已经发过了”。说明书给了两种可选的模式，初次启动时在选择画面二选一：

• 模式一，发送日志文件管理：抽取前查发送日志，日志里没有的才捞；抽出成功后把指图号写进日志。
• 模式二，指图用户状态管理：抽取前查指图的用户状态 SEND 是否为 ON，非 ON 才捞；抽出成功后把 SEND 置 ON。

两种模式的差别在可回溯性。日志文件是旁路记录，指图本身不带痕迹，日志丢了就不知道发没发过；用户状态直接挂在指图上，谁都能在系统里看到，但会占用一个业务状态位，和有其他业务状态管理需求的场景可能打架。我一般倾向模式二，因为出问题时业务顾问自己能查，不用来找开发捞日志。

下面是抽取主体的示意代码，表名字段按你系统里的实际结构调整，逻辑是一致的：

DATA: lt_afko TYPE TABLE OF afko, ls_afko TYPE afko. " 参数：p_from / p_to 着手日区间，p_werks 工厂，p_mode 管理模式 SELECT a~aufnr a~plnbez a~gamng a~gstrp a~werks a~dispo INTO CORRESPONDING FIELDS OF TABLE lt_afko FROM afko AS a INNER JOIN afpo AS b ON b~aufnr = a~aufnr WHERE a~gstrp BETWEEN p_from AND p_to " 着手日在区间内 AND a~werks = p_werks " 限定单工厂 AND b~delfg = space " 未取消 AND a~aufnr NOT IN ( SELECT aufnr FROM zt_mes_sendlog ). " 模式一 " 模式二：再剔除用户状态 SEND 已 ON 的指图 " 状态判断走状态表（JEST / JSTO），此处省略查询细节， " 核心是：已置 SEND 的指图必须从内表里删掉，否则会重复下发 IF p_mode = '2'. LOOP AT lt_afko INTO ls_afko. IF zcl_mes_status=>has_send_flag( ls_afko-aufnr ) = abap_true. DELETE lt_afko. ENDIF. ENDLOOP. ENDIF.

gstrp是着手日，delfg是删除标记，这两个字段的判断顺序建议固定下来：先按索引友好的条件过滤掉大头，再在内存里做状态判断。因为状态查询是逐条读表，放到数据库层做子查询反而慢。生产量大的时候，这一步的耗时能差出好几倍。

参数说明：日期区间不建议开太宽。这个区间是配合 MES 侧的产能排程来的，一般是“今天往前 N 天”，N 由参数文件配置；开成一年，每次跑都全表扫，一周之后就该被 DBA 找上门了。

3.2 文件写出：存在就追加，不存在就新建

写文件的规则一句话就能说完：目标文件存在则追加，不存在则新建后追加。落到实现上，就是以追加模式打开数据集，逐行写。改行码由变式带进来，Windows 形式用CR_LF，Unix 形式用换行符。

DATA: lv_line TYPE string, lv_eol TYPE string. " p_eol_type 来自参数文件：'WIN' 或 'UNIX' IF p_eol_type = 'WIN'. lv_eol = cl_abap_char_utilities=>cr_lf. ELSE. lv_eol = cl_abap_char_utilities=>newline. ENDIF. " 追加模式打开：文件不存在时会自动创建 OPEN DATASET p_out_path FOR OUTPUT IN TEXT MODE ENCODING DEFAULT. IF sy-subrc <> 0. PERFORM write_log USING 'E' '文件打开失败' p_out_path. EXIT. ENDIF. LOOP AT lt_afko INTO ls_afko. CONCATENATE ls_afko-aufnr ls_afko-werks ls_afko-plnbez ls_afko-gamng ls_afko-gstrp INTO lv_line SEPARATED BY '|'. CONCATENATE lv_line lv_eol INTO lv_line. TRANSFER lv_line TO p_out_path. ENDLOOP. CLOSE DATASET p_out_path.

p_out_path是逻辑路径，不是硬编码的物理路径。逻辑路径在参数文件里定义，程序里只引用逻辑名，这样测试环境和生产环境换目录不用改代码。这个做法在二十年前叫“逻辑路径”，放到今天对应的就是配置项外置，道理一样。

TRANSFER每行写一次，这里没做缓冲。数据量大时可以拼一个内表批量写，但那会引入“写到一半失败”时的不完整行问题，取舍看你更怕性能还是更怕脏数据。批处理一天一两轮，我倾向牺牲性能换整行完整性。

日志同样重要。开始时写一条开始记录，结束时写一条带总件数和成功失败数的终了记录，中间按行写明细。日志保留期限也是参数之一，说明书里明确要求可配置——这不是形式主义，日志文件是排障时的黑匣子，保留期太短，等你发现问题时现场已经没了。

3.3 后处理与两种管理模式的分叉

抽出正常完成后，程序要做收尾动作：模式一下把本次抽出的指图号写进发送日志；模式二下把这些指图的用户状态 SEND 置 ON。这一步必须是最后做，而且只在整体成功时做。

" 只在无错误的情况下回写，避免部分成功被标记为全部发送 IF lv_err_cnt = 0. IF p_mode = '1'. LOOP AT lt_afko INTO ls_afko. ls_log-aufnr = ls_afko-aufnr. INSERT zt_mes_sendlog FROM ls_log. " 记发送日志 ENDLOOP. ELSE. LOOP AT lt_afko INTO ls_afko. PERFORM set_user_status_send USING ls_afko-aufnr. " 置 SEND = ON ENDLOOP. ENDIF. ENDIF. COMMIT WORK.

这里的顺序是有讲究的：先写文件，再写标记。反过来先打标记再写文件，中间进程挂掉，这批指图就既没发出去、又不会被下一轮捞到，属于典型的“静默丢单”。这个坑我踩过，一批急件在车间凭空消失了一整天，最后靠对账才发现。

注意：如果抽出一部分成功一部分失败，不要做“部分回写”。要么整批标记，要么整批不标记，让下一轮重来。重复下发比漏发好处理得多，因为 MES 侧有唯一键去重。

4. 实绩计上接口 ZMAF005：从文本文件到作业确认的落地路径

反方向的这段更麻烦。抽出是“我说了算”，计上是“别人给我什么我得校验什么”。MES 侧交上来的数据带着车间现场的复杂性：BOM 里没有的料、反冲件、分割后再合并的批次、部分确认和最终确认混在一起。

4.1 先落工作区，再动业务数据

说明书里有一句非常关键的话：为防止处理异常终了时的二重计上，先把数据放进工作用的数据库。翻译成工程语言就是——别在读文件的同时边读边记实绩，先做一次“入库暂存”，把幂等判断和业务写入拆成两个阶段。

" 阶段一：读文件，按唯一键过滤掉已处理过的记录 OPEN DATASET p_in_path FOR INPUT IN TEXT MODE ENCODING DEFAULT. DO. READ DATASET p_in_path INTO lv_line. IF sy-subrc <> 0. EXIT. ENDIF. APPEND lv_line TO lt_raw. ENDDO. CLOSE DATASET p_in_path. LOOP AT lt_raw INTO lv_line. SPLIT lv_line AT '|' INTO ls_rec-aufnr ls_rec-matnr ls_rec-qty ls_rec-budat ls_rec-seq. " 唯一键判重：同样的指图 + 品目 + 作业日 + 连番视为再送 SELECT SINGLE seq FROM zt_conf_done INTO lv_seq WHERE aufnr = ls_rec-aufnr AND matnr = ls_rec-matnr AND budat = ls_rec-budat AND seq = ls_rec-seq. IF sy-subrc = 0. CONTINUE. " 已处理过，直接跳过，不报错 ENDIF. APPEND ls_rec TO lt_work. ENDLOOP. " 阶段二：暂存到工作区表，先提交，再逐条计上 INSERT zt_conf_work FROM TABLE lt_work. COMMIT WORK.

zt_conf_done是处理完成表，zt_conf_work是暂存工作区，两张都是自建表。为什么不能只靠删文件来防重？因为文件和数据库不在一个事务里：业务写完、文件还没删，进程崩了，下一轮又会读到同一批数据。有了完成表加上唯一键，重复读取不会造成重复计上。

seq是行内连番，MES 侧生成，用来区分同一指图同一品目同一作业日的多行记录。这个字段看着不起眼，缺了它，一个班次分两次报工的数据会被当成重复行吞掉。

4.2 业务校验：反冲件、BOM 缺失、完了区分

计上之前有一组必须做的业务校验，说明书里点明了两种会报错的情况。

第一种是反冲品目。反冲件在 ERP 里的投入是自动倒冲的，MES 侧再报一次投入实绩就是重复计数，所以说明书要求直接判错并写日志，数量要改只能去 ERP 的作业确认界面手工改。判断依据是 BOM 组件上的反冲标志：

SELECT SINGLE rgekz FROM resb INTO lv_rgekz WHERE aufnr = ls_rec-aufnr AND rspos = ls_rec-rspos. IF lv_rgekz = 'X'. " 反冲品目不允许从 MES 计上投入实绩 PERFORM write_log USING 'E' '反冲品目不可计上' ls_rec-aufnr. lv_err_cnt = lv_err_cnt + 1. CONTINUE. ENDIF.

第二种是 BOM 里不存在的组件。说明书要求构成品目必须在指图发行时点就已经登记在 BOM 里，MES 报上来一条 BOM 里没有的料，直接判错。这条限制看着严苛，实际是保护：凭空多出来的物料消耗会让成本核算彻底失真，而且事后很难追溯是哪一笔记错的。

完了实绩这边要处理的是确认区分。MES 侧在完了数据上打“部分确认”或“最终确认”标记，前者只更新产出数量，后者才结束指图。这个标记必须在文件格式里明确定义，不能靠数量凑巧等于计划量来推断——现场补报、超报都很常见。

4.3 累计实绩与日别实绩，二选一

说明书提到 MES 侧交上来的实绩有两种口径：作业对应的累计实绩，或者按作业日拆开的日别实绩。运行时的变式里选。这两者不能混。

累计口径下，同一指图第二次报的是“到目前为止总共做了多少”，程序要用后值覆盖前值或者算差额；日别口径下，每条记录是“这一天做了多少”，直接累加。选错了口径，产出数量会指数级放大或者直接归零，而且不会报错，只是数字不对。

我的做法是在参数文件里把口径写死，并且让程序在启动时打印一行日志说明当前口径，出问题时一眼能看出来。别指望操作员记得上次选了什么。

4.4 计上、日志与文件删除的收尾

校验通过后调用确认相关的功能模块把实绩记到指图上。常见做法是用批量确认的 BAPI，输入表按时间票组织：

CALL FUNCTION 'BAPI_PRODORDCONF_CREATE_TT' EXPORTING posting_date = ls_rec-budat " 计上日期 TABLES time_tickets = lt_tickets " 确认行：指图号、工序、产出、不良、工时 detail_return = lt_detail_ret IMPORTING return = ls_return. IF ls_return-type CA 'EA'. " 单条失败不影响整批，记录下来继续下一条 PERFORM write_log USING 'E' ls_return-message ls_rec-aufnr. ELSE. " 成功才写完成表，作为幂等依据 INSERT zt_conf_done FROM ls_done. ENDIF.

单条失败继续处理下一条，这点很重要。一批两百条里有一条 BOM 缺料，不应该让另外一百九十九条都卡住。但要保证失败的那条不写完成表，下一轮还能重试。

全部处理完之后才删接口文件，而且删的是“已成功处理的记录”对应的整个文件——如果存在失败记录，文件保留，等人工处理完再跑一轮。日志同样是开始/终了两条加明细。

注意：不要在循环里 COMMIT。按批次提交，一次几十条，既不会长事务锁表，也不会因为一次提交失败丢掉全部结果。

5. 排他与幂等的排查清单：文件锁、唯一键和重复计上的五个坑

这套设计的排他机制看着简单到有点土：处理前建一个管理文件，处理完删掉；文件在，说明对方在跑，本轮直接退出。但越是简单的东西，现场出的问题越集中在几个固定位置。

5.1 管理文件的正确姿势与它的天花板

先看基本流程。写侧只追加、读侧处理完才删、双方都靠管理文件互斥，这三条构成了整套同步规则。实现上有个细节必须注意——不能用“以输出模式打开数据集”来当抢锁动作。ABAP 里以输出模式打开一个已存在的文件，不会失败，而是把内容清空重写。也就是说：

" 错误示范：以为打开失败就代表被人占了，实际上会直接覆盖 OPEN DATASET p_lock FOR OUTPUT IN TEXT MODE. IF sy-subrc <> 0. EXIT. ENDIF. " 正确做法：先判断存在性，再做原子性抢占 " 1) 写一个带进程标识的临时锁文件 CONCATENATE p_lock_dir '/lock_' sy-uname '_' sy-datum sy-uzeit INTO lv_tmp_lock. OPEN DATASET lv_tmp_lock FOR OUTPUT IN TEXT MODE. TRANSFER sy-uname TO lv_tmp_lock. CLOSE DATASET lv_tmp_lock. " 2) 重命名到正式锁名，重命名失败说明已被别人抢先 RENAME DATASET lv_tmp_lock TO p_lock. IF sy-subrc <> 0. " 抢锁失败，本轮不处理 EXIT. ENDIF.

RENAME DATASET在多数操作系统上是原子操作，抢夺失败会返回非零。这比检查存在再创建的两步法安全，因为两步法中间有窗口期，两个作业同时启动就能双双通过检查。

锁文件里写占用者和时间戳，是为了处理另一种情况：进程异常终止，锁没删掉，下一轮永远被挡住。带时间戳的锁文件可以被人工或定时任务识别成“僵尸锁”清掉。

这个方案的天花板也要说清楚：它适合一天一两轮、竞争不激烈的场景。真要做到秒级并发，得上数据库锁或者队列，文件锁撑不住。

5.2 五个真实会遇到的坑

坑一：同一批实绩被计上了两次。现象是某张指图的产出数量翻倍，成本也翻倍。原因通常是处理完业务数据、还没删文件时进程被杀，下一轮重新读到同一批数据；或者完成表写入失败但业务已经提交。解决是把“完成表写入”放在业务提交的同一个逻辑单元里，并且补一个按唯一键的事后对账脚本，定期扫出重复记录。

坑二：文件读出来是乱码或者整行粘在一起。现象是明明看着是四行，程序读成一行。原因是改行码配置和实际不符——写侧按 Unix 换行写，读侧按 Windows 换行解析，或者中间经过了某个环节做了字符转换。这套设计明确说了不做代码转换，透传，所以双方必须对齐。解决是在参数文件里把改行码做成显式配置项，并且在上线前用真实环境各写一份、互读一次验证，别只在自己机器上试。

坑三：抽取跑完是零件，但明明有一堆待发的指图。现象是日志显示选出 0 条。原因多半是上一轮已经把 SEND 状态置 ON 了，而这一轮又选了模式二；或者是着手日区间配成了“往前 0 天”。解决是让程序在日志里打印本次实际使用的参数值——区间起止、管理模式、工厂，别只打印“处理完成”。参数问题占了这类故障的一大半。

坑四：反冲品目报错日志刷屏。现象是每轮几百条“反冲品目不可计上”。原因往往是 MES 侧的报工界面对所有组件一视同仁地采集投入数量，没区分反冲件。这不是程序问题，是接口约定没传达到位。解决是在接口规格文档里单独列一节写明哪些组件类型不允许报投入，并且让 MES 侧在采集界面上就过滤掉，别指望 ERP 侧兜底报错。

坑五：文件被对方在自己的处理过程中删掉了。现象是读到一半读不到数据，或者处理到中途文件消失。原因是删除动作的归属搞错了——写侧写完后顺手清理，或者读侧在处理前先删后读。解决是把“谁写谁追加、谁读谁后删”写进接口契约，并且在代码里加断言：写侧代码里不应该出现 DELETE DATASET，读侧的删除必须放在处理成功之后。这种约定靠代码评审守，比靠文档守靠谱。

6. 二次开发：把这套雏形改造成你自己项目的接口规范

这份说明书本身定位就是雏形——给新项目做接口原型时能快速搭起来、快速验证。所以要动它，方向不是“优化性能”，而是“把里面写死的东西变成可配置的”。

几个值得优先改造的点：

改造顺序我建议从错误汇总表开始。原因很实际：这套设计最耗人力的不是正常流程，而是出错之后要从几百行日志里翻出是哪张指图、哪条记录、什么原因。把它结构化到一张表里，运维成本立刻降一个台阶，而且不影响任何现有逻辑，风险最低。

验证方法上，别只跑正常路径。准备四组数据：正常指图、反冲件指图、BOM 缺件指图、同一指图连报两次的实绩。四组跑完，去看三处——接口文件的实际内容、完成表里的记录数、指图上的确认数量。三处对得上，才算通。这个清单我每次都强制走一遍，因为它能覆盖住绝大部分现场会遇到的组合。

最后说个习惯。这套东西最贵的不是代码，是那句“指图发行后由 MES 侧管理、实绩计上后由 ERP 侧修正”。这条边界要是没在项目启动时和业务方确认下来，代码写得再漂亮也白搭——两边都觉得自己有权改，数据迟早对不上，而且这种对不上没有后悔药可吃。从那以后我每次接手接口类项目，都会先把“谁写、谁读、谁删、谁改”这四件事画成一张表让双方签字，再动第一行代码。

希望帮到你。

本文还有配套的精品资源，点击获取