企业官网建设流程全解析

简介：面向 SAP R/3 与制造执行系统（MES）集成场景的接口设计说明书，适合从事 ERP-MES 对接的 SAP 顾问、ABAP 开发与 MES 实施人员参考。文档以 MELEBUS-BMAS 模板为背景，围绕制造指图数据抽取与实绩数据计上两条主线，梳理系统间接口的定位、适用前提与职责边界，正文以日文撰写，术语沿用 SAP 与 MES 侧的惯用表述。压缩包内含 1 个 doc 文件，约 178KB，体量不大却覆盖系统规格、接口文件规格、程序规格与参数设定四部分，给出 ZMAF001、ZMAF005 两段程序说明、接口文件一览与字段定义，并配有 R/3 与 MES 间的排他控制、同步处理机制说明及想定业务流程图。目前已有 2668 人学习。读者可从中了解接口雏形的搭建方式、变体化配置项（改行代码、文件逻辑路径、日志保留期限）、指图抽取管理方式的选择，以及接口文件格式与实绩计上的处理逻辑，可作为对接方案设计与联调排错的参考底稿。

1. 需求：两个系统每天对不上账，问题往往不在业务逻辑

制造现场最常见的 MES 接口形态，不是实时消息队列，而是两个系统往同一个共享目录里扔文本文件。ERP 侧每天凌晨把当天要做的制造指图导出来，MES 侧早上取走派工；晚上 MES 把投入实绩和完成实绩写回去，ERP 侧再跑一批计上。整套 MES 接口设计说明书写的就是这两条链路：什么时候抽、抽哪些指图、文件里放什么字段、谁负责删文件、两个系统同时伸手怎么办。这类方案最适合正在做 ERP 与 MES 对接课程设计、毕业设计，或者要给工厂交付一份接口说明的读者——它要求的不是多高深的算法，而是把边界、时序、异常三条线一次讲清楚。

2. 总体设计：两条主链路、一份文件清单与三层排他

2.1 系统化对象范围：只做两条链路，别把 MES 侧功能画进来

整套接口被切成两个方向完全相反的处理，必须在设计文档第一页就写死，否则后面开发和验收会互相扯皮。

第一条是制造指图数据抽出，方向是从 ERP 到 MES。ERP 侧把制造指图的头信息和构成品目数据拔出来，写进指图接口文件和构成接口文件两个文本文件。MES 侧拿到后派工、拆分、打印现品票、下到工位。

第二条是实绩数据计上，方向是从 MES 回到 ERP。MES 把投入实绩（哪個品目投了多少）和完成实绩（确认了多少良品、多少不良、预测终了日）写成文件，ERP 侧读取后挂到对应制造指图上，形成作业实绩。

关键边界在于：MES 侧接口本身的实现不在本追加功能范围内。说明书里出现的 MES 行为，比如日别汇总、部分确认与最终确认的区分、指图拆分后的合并计上，都是对 MES 的一种前提假设，不是交付内容。我在做这类文档时一般会把这句话单独加粗放在章节开头，因为它能挡掉至少一半的验收争议——对方会问「为什么 MES 那边的界面没有」，答案就在这一句。

还有几条隐含范围要写清楚。一个工厂内 ERP 与 MES 的连携，不做跨工厂。目标生产方式限定在「会发行制造指图」的那种，流程式无指图的生产不适用。抽取和计上都是批处理，一天一到两回，不做实时。

2.2 前提条件：OS、文件共享和批处理周期，缺一条方案就不成立

接口设计最容易翻车的不是字段错，而是运行环境前提没写进文档，实施时被当成「应该都行」。下面这张表是我一般会附在前提条件子章节里的版本，参数表里的每一项都能在后面的变体设置里找到对应项。

移动文件、改行码、逻辑路径这三件事，全部通过变体参数控制，不写死在程序里。原因是同一套程序要能装到不同客户的现场，现场的操作系统组合不一定一样。我见过一个项目把改行码写死成 CRLF，结果 MES 侧是 Unix，读取程序按 CRLF 切分，整整一个月的指图被当成一条超长记录，日志里只有一行「记录长度异常」，排查了两天才定位。

批处理周期这条也要说透。一天一到两回意味着接口文件是「攒批」的，不是「来一条处理一条」。攒批带来的直接结果就是文件会持续追加、消费端跑一次可能拿到几十上百条记录、任何一条数据有问题都会拖住整批。设计上必须允许单条失败不影响其他记录，日志要能定位到具体是哪一条。

2.3 接口文件清单、唯一键与参数变体

文件一共四类，两进两出，我把它们整理成一张清单，写进说明书时这张表本身就是交付物的一部分。

四个文件都必须带唯一键。指图类文件的唯一键用「指图号 + 指图行项目」，实绩类文件用「指图号 + 作业号 + 计上日期 + 品目」。唯一键的作用不是校验，是让读取端能识别「这条是不是重发的」——写入端只追加不覆盖，网络抖动或程序重跑都可能让同一条记录出现两次，读取端靠唯一键做一次判重，就能把重复挡在计上之前。这一点在实绩链路上尤其要紧，重复计上等于账面上多做了一批货。

参数变体是整个方案里最容易被低估的设计。需要变体化的项至少包括：改行码（CRLF 还是 LF）、接口文件的逻辑路径、日志保存期限、抽取时的日期窗口天数、指图管理方式、实绩计上的种别、处理模式。做成变体而不是常量，好处是同一套程序在现场调整时不用改代码、不用重新传输请求，改配置表就行。我一般会把变体项做成一张二维表：行是变体名，列是参数，附在说明书参数设定章节里，实施时照着填。

2.4 三层排他：管理文件、追加写、唯一键去重

两个系统通过共享目录访问同一批文件，天然存在并发。解决办法不是加锁服务，而是三层轻量机制叠起来。

第一层是管理文件。指图处理和实绩处理各有一个管理文件，本质是个空的标记文件。处理开始时创建，处理结束时删除；程序启动先检查管理文件在不在，在就直接跳过本次执行，不等待、不重试。这一层解决的是「两个系统同时处理同一批文件」的问题，作用域粗但足够。为什么用文件而不是数据库锁？因为两侧是异构系统，共享目录是唯一都认的公共资源，文件存在性判断是成本最低的跨系统信号。

第二层是写入方式。写入侧永远用追加模式，绝不覆盖；已经写进去的记录由读取侧在处理成功之后统一删除。这条规则把「谁有权改文件」这件事定死了：写的人只加，读的人只删，中间不存在任何修改动作。好处是即使一方中途崩了，文件里存量的数据仍然完整，重跑一次就是重放，不会出现半个文件。

第三层是唯一键判重。前面说过，读取侧在处理每条记录前先比对唯一键，已经处理过的直接丢弃。这层兜住的是「文件没删干净」「重发」「日志与实际不一致」这三类残余问题。

三层机制里，第一层防并发，第二层防数据损坏，第三层防重复业务。任何一层单独用都不够：只有管理文件，处理异常退出后文件残留会让人工判断；只有追加写，两个系统还是会撞；只有唯一键，同一批数据会被处理两遍再丢掉一半，日志里全是噪音。三层一起上，才叫可交付。

3. 制造指图抽取接口：五道过滤、文件追加与 SEND 打标

3.1 抽取条件：日期窗口加四道状态过滤

抽取不是把 ERP 里所有指图都倒出来，那样 MES 侧会被历史数据淹掉。过滤条件一共五道，缺一道都会出问题。

第一道是着手日窗口。以参数文件里指定的起算日为界，只取着手日落在窗口内的指图。窗口天数做成变体，通常给 3 到 7 天，太短会漏掉提前派工的指图，太长会把远期计划也推下去。

第二道是系统状态。必须是已发行状态，同时排除已完成和技术完成的指图。已完成的不该再派，技术完成的属于收尾，都不需要下现场。

第三道是有效性。取消掉的指图不能抽，这条看似废话，但 ERP 里作废指图的状态组合有好几种，只判断一个标志位会漏。

第四道和第五道是二选一的指图管理方式，在初次启动时通过选择变体决定用哪种：

• 方式一，发送日志重复检查。抽取前查发送日志文件，里面没有的指图才抽。适合没有启用用户状态的现场。
• 方式二，用户状态管理。指图被抽走之后在 ERP 侧把用户状态 SEND 置为 ON，下次抽取排除 SEND 已 ON 的指图。适合现场已经在用用户状态做流程管控。

两种方式不要混用。混用的后果是抽取条件互相打架，一部分指图被日志挡住、一部分被状态挡住，日志和状态表对不上，后续想追溯「这张指图到底发没发」会非常痛苦。选型建议很直接：现场有用户状态管理习惯就选方式二，因为它和 ERP 的业务操作是同一套语言；没有就选方式一，日志文件是纯接口层的产物，不污染业务数据。

3.2 抽取处理：有文件就追加，没文件就新建

抽到数据之后写文件，逻辑很简单但必须写清楚：接口文件不存在就新建，存在就追加，两种情况都是追加语义，不做覆盖。指图头信息和构成品目分别写进两个文件，靠指图号关联。

下面这段是抽取程序 ZMAF001 的骨架，实际实现里状态判断要查状态表，这里用伪代码表达顺序关系。

" ZMAF001 制造指图抽取主流程（骨架示意） " P_CTRL : 管理文件所在逻辑路径，来自变体 " P_OUT : 指图与构成文件的输出目录，来自变体 " P_FROM : 着手日窗口起算日，来自参数文件 " 1) 管理文件存在说明对侧正在处理，本次直接退出，不等待 IF file_exist( p_ctrl && 'ZMAF001.LCK' ) = abap_true. MESSAGE '对侧处理中，本次不输出' TYPE 'S'. EXIT. ENDIF. " 2) 占住指图处理通道 file_create( p_ctrl && 'ZMAF001.LCK' ). " 3) 五道条件取数：着手日窗口 + 已发行 + 未完成 + 未取消 + 未发送 SELECT * FROM afko INTO TABLE lt_order WHERE gstrp >= p_from AND gstrp <= p_to AND objnr NOT IN ( SELECT objnr FROM jest WHERE inact = 'X' ). " 排除取消/删除标记 " 4) 按变体二选一过滤：查发送日志，或排除用户状态 SEND LOOP AT lt_order INTO ls_order. IF gv_mode = 'LOG'. CHECK NOT log_exists( ls_order-aufnr ). ELSE. CHECK NOT user_status_on( ls_order-aufnr, 'SEND' ). ENDIF. APPEND ls_order TO lt_send. ENDLOOP. " 5) 追加写：文件不存在则新建，存在则续写，不覆盖 APPEND_TO_FILE( p_out && 'ORDER.txt', lt_send ). APPEND_TO_FILE( p_out && 'COMPONENT.txt', lt_comp ).

这段代码里有三个设计判断值得展开。第一个是管理文件的检查放在最前面，先于任何取数动作，因为取数本身耗时，等取完再检查就失去了排他意义。第二个是APPEND_TO_FILE统一封装追加语义，不写WRITE覆盖，从代码层面杜绝误覆盖。第三个是过滤放在取数之后而不是塞进 SQL，原因是两种管理方式的数据源不同，塞进 SQL 会写出两套语句，维护成本翻倍。

参数上还有两个细节要说明。着手日窗口的上下界都从参数文件读，不在代码里写死，这样现场调整窗口不需要改程序。指图类型不参与过滤但必须输出到文件里，因为特急指图和手直修指图在 MES 侧要走不同的派工路径，靠指图类型区分，所以 ERP 侧要给建议：特急、手直修用独立的指图类型管理，别用备注字段。

3.3 日志双文件：一个看结果，一个看过程

日志分两个文件，职责不同。

开始结束文件记录每次执行的结果：什么时候开始、什么时候结束、处理了多少条、有没有异常。它是给运维看的，一眼能判断「昨晚跑没跑、跑成没成」。

明细日志按记录单位写，每条指图一行，写清楚指图号、抽取结果、跳过原因。它是给排查用的，当 MES 侧说「某张指图没收到」，查这个文件就能知道是抽取条件没过、还是写了但被对侧删了。

两个文件都受日志保存期限变体控制。期限别设太长，明细日志一天几千行，一年下来占用不小；也别设太短，我一般建议覆盖一个完整的月末结算周期，至少 45 天。

3.4 抽取后处理：SEND 打标必须在正常终了之后

如果用用户状态方式，抽取成功之后要把被抽走的指图的 SEND 状态置 ON。这条动作的位置很关键：必须放在整个抽取流程正常终了之后，不能边抽边打标。

原因是中途异常时会出问题。假设抽到第 50 条时文件写入失败，如果前 49 条的 SEND 已经打上，下次重跑这 49 条会被当成已发送而跳过，但它们其实没写进文件——数据就这么丢了，而且丢得无声无息。正确顺序是：取数、写文件、确认写成功、再统一打标。打标本身也放在管理文件保护范围内，防止打标打到一半对侧开始处理。

4. 实绩数据计上接口：先落工作库，再动制造指图

4.1 MES 侧输出约定：按指图汇总、带部分与最终确认区分

MES 侧的输出逻辑要作为前提在说明书里写清楚，因为它决定了 ERP 侧怎么读。

MES 会按制造指图单位、按日汇总投入实绩和完成实绩，然后写进接口文件。MES 内部对制作指示书的拆分和合并，由 MES 自己消化，写出来的时候已经归并回一张制造指图。ERP 侧不做拆分合并，拿到什么就是什么。

完成实绩必须带确认区分：部分确认还是最终确认。这个字段是 ERP 侧判断「这张指图能不能关掉」的唯一依据，缺了它，指图会一直挂在未完成状态。同一张指图可能先来一次部分确认，隔天再来一次最终确认，两次都要处理，不能因为「已经计过上回了」就跳过。

还有一条要写死：实绩数据一旦计上，不从 MES 侧发变更或取消数据。要改就改 ERP 侧。这条限制看着不近人情，但它把双向同步这个最麻烦的问题直接砍掉了，接口的复杂度降一个量级。

4.2 ERP 侧登记：处理完检查、工作库、正式计上、删文件

实绩计上的顺序比抽取严格得多，因为涉及真正的账务数据。四步固定下来：

第一步，处理完检查。读文件里的每条记录，先查唯一键是否已经计上过，已处理的直接跳过。

第二步，落工作库。这是防二重计上的核心。整批数据先写进一张工作用的数据库表，写入时靠唯一键约束挡住重复。

第三步，逐条计上正式表。投入实绩写投入品目和数量，完成实绩写确认良品数、确认不良数和预测终了日。单条失败写日志，继续处理下一条。

第四步，全部处理完毕后删除接口文件。

-- 实绩文件先落工作库，唯一键 UK_ACT 挡住重发与重跑 -- zt_mes_act_in : 文件读入的临时表 -- zt_mes_act_wk : 工作库，UK_ACT 上建唯一索引 INSERT INTO zt_mes_act_wk ( uk_act, aufnr, vornr, budat, matnr, menge, kzcha ) SELECT s.uk_act, s.aufnr, s.vornr, s.budat, s.matnr, s.menge, s.kzcha FROM zt_mes_act_in s WHERE NOT EXISTS ( SELECT 1 FROM zt_mes_act_wk w WHERE w.uk_act = s.uk_act );

字段含义：uk_act是唯一键，由指图号、作业号、计上日期、品目拼成；aufnr指图号；vornr作业号；budat计上日期；matnr品目；menge数量；kzcha确认区分。NOT EXISTS这一段就是防重入口，同一批文件重跑两遍，第二遍一条都插不进去。

为什么要多这一层工作库，而不是直接计上？因为计上动作本身可能中途异常。假设直接写正式表，写到第 30 条时数据库连接断了，前 29 条已经生效、文件还没删，第二天重跑会把前 29 条再计一遍。有了工作库，第二次跑的时候NOT EXISTS直接挡掉，只有第 30 条之后的会重新处理。这个「后悔药」不是可选项，是必选项。

计上处理同样受管理文件保护，处理期间创建实绩处理管理文件，对侧处理中则不执行。

4.3 累计实绩与日别实绩：变体切换的两种口径

MES 侧传来的实绩数据有两种口径，运行时通过变体选择。

一种是作业累计实绩：文件里的数字是这张指图这张作业到目前为止的总投入和总完成。ERP 侧拿到后做的是覆盖式更新，用新值替换旧值。

另一种是作业日别实绩：文件里只放当天新增的数量。ERP 侧做的是累加，把当天数量加到已有实绩上。

这两种口径选错，账会错得很离谱：日别数据被当累计处理，第二天的数量会把第一天的覆盖掉，最终数量永远等于最后一天；累计数据被当日别处理，每天累加一遍，数量会翻好几倍。所以这个变体项必须在实施前和 MES 侧确认清楚并写进文档，不能靠猜。我的习惯是在参数表里加一列「口径确认人」，谁确认的写谁，出问题时有据可查。

4.4 四类必然报错的数据，提前在文档里写死

有几类数据一定会报错，与其让它在日志里反复刷，不如在说明书里列清楚，让现场提前规范操作。

反冲品目的投入实绩。反冲品目在 ERP 里是自动扣料的，MES 侧再计一次投入就会被判为重复，写进日志报错。要改反冲品目的投入数量，走 ERP 的作业确认手工输入，不走接口。

BOM 里不存在的品目。投入实绩的品目必须在指图发行那一刻就已经在 BOM 里。制造上临时加的料，如果没进 BOM，接口计上会被拒。解决办法是现场先把 BOM 维护好，接口不承担补料职责。

指图号不存在的记录。MES 侧拆分后如果归并逻辑有误，可能写出一个 ERP 里没有的指图号。这类记录直接报错，不做自动创建。

重复唯一键。同一条实绩在文件里出现两次，第二次被工作库挡掉，日志里记录一条跳过。

这四类不要试图在程序里做自动纠正。接口的职责是忠实传递和明确拒绝，自动纠正会把问题藏起来，等到月末对账才发现，那时候追溯成本高得多。

5. 常见问题排查：五类最容易翻车的接口故障

5.1 文件被对侧提前删了，抽取端还在往里追加

现象：ERP 侧抽取日志显示写入成功，MES 侧却说没收到数据；或者文件大小忽大忽小，明明追加了几十条，过一会儿又变回几百字节。

原因：删除动作没有遵守「只有读取侧在处理成功之后才能删」这一条。常见变体是 MES 侧为了清理目录，加了一个定时任务把超过一定时间的文件统统删掉，完全不管有没有处理过。两个动作撞在一起，写入端的追加就落到了一个已经被删掉又重新创建的文件句柄上。

解决：把删除权限收归读取侧程序，删除动作放在处理成功之后、日志写完之前，中间不插入任何其他操作。目录清理任务要么取消，要么改成只清理已经改名的归档文件。同时在说明书里明确写一句：接口文件的生命周期由读取侧管理，写入侧不得删除、不得改名。

5.2 反冲品目被反复计上，日志里刷出一屏错误

现象：实绩计上日志每天出现大量「品目不可投入」的错误，涉及的品目集中在几个固定料号上，数量对不上。

原因：MES 侧把反冲品目也当成普通投入品目输出了。反冲的逻辑是 ERP 在确认完成时按 BOM 自动扣料，MES 再计一次就重复了。这不是程序 bug，是业务口径没对齐。

解决：两个动作。一是在 MES 侧输出逻辑里排除反冲品目，从源头不写；二是在 ERP 侧计上程序里对反冲品目做一次判定，命中就写日志跳过，不报错中断。第二道是兜底，防止 MES 侧改动遗漏。同时把这条写进说明书的业务前提章节——反冲品目的投入数量变更走 ERP 手工确认，不走接口。

5.3 改行码不一致，整个文件被读成一条记录

现象：MES 侧取入时报「记录长度异常」或者只处理了一条记录，日志里记录的条数是 1，但文件明明有几百行。

原因：ERP 侧写的是 CRLF，MES 侧按 LF 切分，整个文件被当成一行超长字符串。或者反过来，Unix 侧写 LF，Windows 侧按固定长度读，读到换行符位置错乱。

解决：改行码必须走变体，不能写死。ERP 侧写入时按变体决定用哪种换行符，MES 侧读取时也读同一个变体值。实施阶段做一次联调验证：写三条记录，让对侧读，读出来的条数必须是 3。这条验证要写进验收清单，不能靠「应该没问题」。

5.4 抽取跑完了但 SEND 没打上，第二天重复发送

现象：同一批指图连续几天被重复抽出来，MES 侧收到重复派工，现场出现两张一样的现品票。

原因：抽取流程在打 SEND 之前异常退出了。比如写文件成功但打标时数据库超时，程序报错结束，管理文件被清理，下次重跑时这批指图的 SEND 还是 OFF，于是又被抽一遍。如果用的是发送日志方式，则是日志写入失败但文件已写。

解决：打标动作要么全部成功要么全部回滚，放在一个逻辑单元里。更稳的做法是抽取和打标之间不做其他耗时操作，缩短窗口。另一个办法是让唯一键兜底——指图文件也带唯一键，MES 侧取入时判重，重复的不派工。两条一起上：源头尽量不重发，末端能挡住重发。

5.5 实绩计上中途异常，第二天二重计上

现象：某天的实绩计上程序异常终止，第二天重跑之后，账面数量比实际多出一截，多出来的正好是异常那天已经处理的那部分。

原因：直接写正式表，没有中间层。异常发生时前若干条已经生效，文件没删，重跑时这些记录被再处理一次。

解决：工作库必须存在，唯一键必须建唯一索引。落库成功之后再计上，计上成功之后才删文件。三者的顺序不能调换。另外要确认工作库的清理策略——不能一跑完就清空，至少要保留到接口文件删除之后，否则唯一键判重就失效了。

6. 验收与答辩：用一份可复现的测试用例把接口讲清楚

交付一份接口说明书，最容易被问的问题不是「字段什么意思」，而是「你怎么证明它能跑」。答辩或验收时，把下面这张测试用例表拿出来，比讲十页架构图都管用。

用例表要配一条执行脚本，把「造数据、跑程序、比对结果」串起来，能反复跑。我一般会把脚本写成最朴素的批处理加 SQL 查询，不追求自动化框架，因为验收现场的人要能看懂每一步在干什么。

#!/bin/bash # 验收自检：抽取完成后先做格式自检，再交给对侧 FILE=$1 # 统计实际记录数 CNT=$(wc -l < "$FILE") echo "记录数: $CNT" # 检查末行是否有换行符，缺了会导致对侧少读一条 if [ -n "$(tail -c 1 "$FILE")" ]; then echo "末行缺少换行符，对侧可能少读一条" exit 1 fi

这段脚本只做一件事：确认文件末行有换行符。听起来琐碎，但缺少末行换行导致最后一条记录丢失这个坑，我在两个项目里都遇到过，排查时往往先怀疑程序逻辑，最后才发现是文件结尾少了一个字节。

答辩时还有一点值得提前准备：把「不做什么」讲清楚。MES 侧接口不在交付范围、实绩计上后不支持从 MES 侧变更取消、反冲品目不走接口——这三条主动说出来，评委会认为你想过边界；被问出来才说，味道就变了。

从那以后我每次写接口文档，都强制自己先画一张「谁写谁删」的表，再动笔写字段。这张表填不满，说明时序还没想清楚，写出来的字段定义一定是错的。希望帮到你。

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