简介这是一份MES系统与ERP系统对接接口清单面向制造业信息化实施人员、系统集成工程师以及负责车间与供应链管理的项目负责人用于明确两套系统间的数据交互范围与责任边界。文档以表格形式整理了ERP提供给MES的销售订单、物料、供应商、客户、采购订单等主数据与业务数据接口以及MES回报给ERP的外购入库、半成品与产成品完工、销售出库、生产领料、补料等执行结果接口同时补充了HR系统向MES同步组织架构与人员信息的接口。资源包内共1个docx文件大小约25KB内容结构清晰便于直接对照和扩展为实际开发或项目文档模板适合正在规划或优化车间级系统集成的读者快速查阅与复用。1. MES与ERP之间的接口清单比两套系统本身更决定上线成败你会发现一个现象工厂上了MES之后第一周大家聊的是数字孪生第二周聊的是数据大屏到了第一个月所有人都在催IT把MES和ERP的接口做好。数字孪生做得再漂亮如果MES的工艺参数、完工数量、物料批次不能及时回给ERP财务和计划看到的永远是昨天的车间。MES系统与ERP系统对接的接口清单就是从ERP的生产订单到MES的工单、从MES的报工到ERP的收货确认这一路的“会话协议”。这份清单不只是一张表它决定了主数据谁来维护、状态变更谁触发、数量差异何时暴露、接口出错时先找谁。下面把这份清单拆开讲透。2. 先分清接口域MES与ERP对接的6类核心接口MES和ERP之间的边界其实很好记ERP管“该做什么、花了多少钱”MES管“正在怎么生产、做完了多少”。两者都碰工单、物料、批次但粒度不同。ERP关心一张生产订单的总成本MES关心一个托盘里每一件过没过质检。所以接口清单的第一步不是急着列字段而是先把接口域按MES系统功能模块和ERP系统业务流程切分。我一般会在清单开头放一张接口域总表把后续所有报文、存储过程、API调用都归到某个域里这样当ERP顾问和MES工程师吵起来时至少能先确认在吵哪个域。2.1 主数据与计划类接口先回答“做什么、用什么做”这一类接口的方向几乎都是ERP到MES。ERP是制造主数据的主责系统物料编码、BOM、工艺路线、工作中心、供应商信息由ERP发给MESMES只做接收和本地缓存。生产计划执行前ERP把计划订单转成生产订单再生成一条“工单下发”消息推给MES。MES收到后创建车间工单并关联BOM和工艺路线。这一域里的接口字段通常很长但关键的没几个ERP订单号、生产线或工作中心、物料编码、BOM版本、工艺路线版本、计划数量、计划开工和完工时间。容易被忽略的是BOM版本和工艺版本。同一个物料改过一次配方后版本号变了如果接口不透传版本字段MES可能按旧配方领料最后财务核算出现成本偏差。常用的同步策略是全量加增量。首次上线做一次全量主数据同步之后每天零点增量同步变化的数据。生产订单推送这类实时性要求高的接口在ERP事务提交后直接触发尽量别用定时批处理。批处理30分钟一次碰上夜班加单MES那边的操作工能盯着工单列表等到天亮。2.2 执行回报与库存类接口车间的实时状态给ERP这组接口方向与上一组相反从MES到ERP也是故障率最高的一组。报工、完工入库、物料消耗、废品、返工、人员工时每一条都是车间里实际发生的动作必须实时或准实时回传。报工接口的粒度多说一句很多团队为了省事做成整单报工一张工单做完才回传。这在批量生产场合还能忍受在离散制造业或者工序级成本核算场景财务完全不认。常见做法是按工序、按设备、按班次分开回传每道工序完成时发一条“工序完工”消息ERP侧落为完工确认记录。接口清单里要写清楚明细层级报工到工序还是到工单汇总口径是什么哪些工序自动过数哪些必须人工确认。库存类接口里最常见的是物料消耗和成品入库。消耗回传给ERP时要带移动类型比如原材料领用、产线退料、报废出库。移动类型如果两侧编码没对齐下游财务库存会在科目之间乱窜月底对账对不上。移动类型的维护必须以ERP为主MES只能做映射和解释。2.3 质量与财务类接口跨界数据最容易吵架质量接口往往是MES侧的生产检验模块在记录数据但ERP不需要每个测量值都留底只关心不良率和成本。所以质量类接口通常是汇总或例外推送抽检完成把良品数、不良数回传出现判定NG的批次立即推送异常消息而不是把每次测量的数据全部同步过去。这类接口做不好质量部门抱怨没有追溯计划部门抱怨垃圾数据淹没了工单状态。财务类接口是清单里最重的成本数据人工工时、机器工时、作业成本、物料成本。MES把这些数据按生产订单和成本中心汇总后定期给ERP。最稳妥的方式是每天凌晨同步前一日数据因为白班夜班交替时晚班的报工数据可能到第二天凌晨才全部落库。如果当天同步拿到的永远是残缺的工时分摊结果。把接口域汇总成一张表后续设计报文、建库表、配权限都按这张表切分接口域主方向典型业务对象常见同步方式主数据ERP到MES物料、BOM、工艺路线每日增量或事件触发计划ERP到MES生产订单、工单事务提交即触发执行回报MES到ERP工序报工、完工事件触发准实时库存MES到ERP消耗、入库、退货事件触发质量MES到ERP检验结果、不良品事件触发加汇总财务MES到ERP工时、成本、费用每日汇总3. 接口清单怎么落从字段映射到API设计的可抄模板接口清单最终要落到字段级映射否则开发各写各的谁也看不懂。这里给出一套我常用且直接能抄的模板包含字段映射表、报文设计和一个能跑起来对账的SQL。3.1 字段映射表的必填列字段映射表是接口清单的主体我要求团队成员统一按七列来写序号、接口场景、ERP字段、MES字段、类型/长度、转换规则、必填标志。备注单独放不混在核心列里。以工单下发为例映射表大概长这样序号接口场景ERP字段MES字段类型/长度转换规则必填10工单下发AUFNRwo_codevarchar(20)直接映射是11工单下发MATNRmaterial_codevarchar(18)左补零到18位是12工单下发GAMNGqty_plandecimal(15,3)按单位换算系数换算是13工单下发BDATUdue_datedatetimeERP日期转车间本地时区是14工单下发BOM版本号bom_versionvarchar(20)直接映射否这里有两个细节很容易被忽略。一是物料编码左补零很多ERP系统的物料编码是字符型但历史数据存在前导零差异MES侧必须统一做一次规范化否则同一个物料会生成两条主数据。二是日期时区ERP服务器往往在机房车间MES服务器可能在另一个园区甚至跨时区接口里如果只传日期不传时区夜班切换时差一小时就会出现“工单已逾期但状态未开工”的怪现象。3.2 报文设计与幂等键用JSON还是XMLMES和ERP对接老系统里多见XML或EDI新的中间层普遍转成JSON。我的建议是内部接口统一JSON外部监管或供应链要求的报文才保留XML。一个工单下发接口的JSON报文可以这样定义{ interface: MES_ORD_SYNC, version: 1.2, message_id: 20241210-00012345, sent_at: 2024-12-10T08:30:0008:00, data: { erp_order_id: A200000123, material: { code: 000000000123456789, bom_version: BOM20241015V2 }, plan_qty: 150.000, uom: PC, work_center: L01, due_date: 2024-12-12T18:00:0008:00 } }这段报文里message_id是最关键的字段。它是幂等键MES收到后先查接口日志表如果这个ID已经处理过直接丢弃本次消息。ERP在重试或人工重发时也必须带上原message_id否则MES重复创建工单数量翻倍。version字段用于接口演进当BOM结构或字段类型变化时只要版本号不一致接收方可以决定拒绝或走兼容分支。接口的调用方式也要提前约定。同步调用适合工单下达这类需要立即确认的场景MES收到后返回成功或失败。异步消息适合报工、消耗回传这类高频率场景MES把消息放进队列ERP消费端处理失败后可以重新消费。清单里必须标注每个接口是同步还是异步否则开发会默认全部做成HTTP同步一个接口慢导致整条链路阻塞。3.3 落地成可运行的对账SQL接口清单不应该只活在Word里我一般会配套建一张mes_interface_log接口日志表字段包括id、interface_code、message_id、direction、business_key、status、error_msg、sent_at、ack_at。所有接口的请求和回包都往这张表写每天定时跑一个对账脚本。一个最简单的失败统计SQL长这样SELECT interface_code, COUNT(*) AS total_cnt, SUM(CASE WHEN status FAIL THEN 1 ELSE 0 END) AS fail_cnt, MAX(sent_at) AS last_run FROM mes_interface_log WHERE sent_at CURRENT_DATE - 1 GROUP BY interface_code;这个查询按接口码统计过去24小时的调用总量和失败量。fail_cnt突然升高时优先看error_msg里有没有重复键、数据越界、编码转换三类错误。last_run能判断接口是不是彻底停掉有些接口配置错了以后会静默失败日志表里根本没有新记录靠这张表一眼就能看出来。4. 我常用的对接参数与踩坑点物料、版本、批次和状态接口清单在文档里写出来很容易上了生产才见真章。我遇到最多的问题不在接口技术而在业务参数不齐。这里挑四个高频坑详细说。4.1 主数据同步不设版本号后面全是雷物料、BOM、工艺路线这些主数据在ERP里修改是常态但MES侧如果只按“最近更新时间”做增量同步很容易漏掉版本变化。比如物料原材料配方从V1升到V2ERP改了BOMMES本地缓存还是V1工单下发时带的是V2MES按V2建工单但报告里显示的BOM版本却是V1两边数据对不上。解决方法是给主数据接口增加一个version字段MES收到数据后先对比本地缓存中的版本号。版本一致直接跳过不一致则更新缓存并写入一条变更记录。如果工单已经开工主数据变更不建议自动覆盖应该由计划员确认后再同步。接口清单里把这类“变更生效时机”写清楚可以避免很多扯皮。4.2 单位换算和数量精度车间用公斤ERP用吨单位不统一是最隐蔽的坑。某原材料ERP主数据以吨为单位MES车间磅秤按公斤过账如果接口只传数量不传单位报工1000公斤ERP收到后直接记成1000吨月底差异大到没法看。更麻烦的是换算率不是整数时比如从加仑换算到升浮点累加误差会越滚越大。我处理这类问题的标准做法是同步数据时同时带上源单位、目标单位和换算系数MES侧所有数量字段都用decimal而不是float。换算逻辑写成一个公共函数统一调用。def to_erp_qty(mes_qty: float, rate: float) - Decimal: if mes_qty 0: raise ValueError(mes_qty must be 0) result Decimal(str(mes_qty)) / Decimal(str(rate)) return result.quantize(Decimal(0.001))这段代码先把浮点转成Decimal再做除法最后保留三位小数。注意这里rate必须来自ERP主数据不能由MES现场录入否则每个班组的换算口径不一致。还要约定舍入规则四舍五入、向上取整还是向下取整。财务侧通常要求四舍五入到三位MES秤重数据可能保留到两位中间多出来的零头放在接口日志里作为差异记录月底统一处理。4.3 批次、库存移动类型和财务科目标批次追溯是MES和ERP最容易吵架的地方。如果批次由MES生成比如产线按炉批号自动赋码那么MES要把批次号回传给ERPERP按移动类型生成物料凭证。如果ERP没有启用批次管理MES传过去的批次号会直接丢失后续质量追溯断链。如果ERP启用了批次管理则批次号必须由ERP统一下发MES不允许自行编造。这一条必须在接口清单的“业务规则”部分写死判断标准是财务库存账里是否认这个批次。移动类型也有同样的边界问题。国内工厂常见的是借用SAP移动类型语义比如场景移动类型收发标识说明原材料领用出库261发生产订单领料工序完工入下一工位101收内部转移产成品入仓库101收完工入库废品报废551发质量损耗出库无论商业MES还是开源MES比如社区里常见的Carbon本地部署移动类型的定义权都在ERP侧MES只做映射。接口清单里应该有一张移动类型对照表画出MES业务事件和ERP移动类型的对应关系并且把每个移动类型对应的库存更新逻辑、财务科目借贷方向都标出来。不然MES传了正确的数量ERP却记错了科目最后查账要翻一个月的日志。4.4 状态机不同步工单一锁谁也救不回MES工单状态和ERP生产订单状态各自维护一套状态机但必须能互相翻译。常见的映射是MES工单状态ERP生产订单状态触发时机已下达已释放工单下发后已开工生产中首道工序开始已完工已确认末道工序报工完成已暂挂已暂停异常停机或物料缺料已关闭已技术关闭财务结算完毕这个表看起来简单实际跑起来经常出现状态错位。典型场景是ERP已经发完料MES也报工完成但ERP的生产订单还是“已释放”原因是两边对“完工”的定义不一致。MES把最后一道工序报工当作完工ERP却要等所有组件倒冲完毕后才算完工。接口清单里必须写明状态转换的触发条件是哪个业务事件而不是简单地“完工后回传成功”。状态同步的接口建议走异步消息并保留历史状态流。MES每发生一次状态变更就往消息队列里推一条完整的状态对象包含原状态、新状态、操作人、时间戳。ERP按序消费遇到乱序或缺失时可以由人工补偿。这里最忌讳的是只传一个最新状态一旦丢了中间态两边数据永远补不齐。5. 让清单活下来的三个验证技巧接口清单写完之后不能只存在文档管理系统里。我一般会再补三件事让清单在项目上线后仍然能被持续验证和修正。第一件把message_id作为全链路追踪锚点。接口日志里记下message_idMES应用日志、ERP侧凭证号里也带上同一个ID。出问题时用一条命令或SQL就能定位grep message_id20241210-00012345 /var/log/mes-interface/erp-sync.log可以看到消息到了哪一层、在哪一步抛错。如果日志里没有记录别人让你追查时你会发现自己连起点都找不到。第二件每天凌晨跑一次数据对账不只是看接口状态。拿最关键的三个接口工单下发、报工回传、完工入库分别从MES和ERP两侧汇总同一批业务键的数据做差异比较。比如对报工回传SELECT erp_order_id, SUM(confirm_qty) AS confirm_qty FROM mes_work_order_report WHERE report_date CURRENT_DATE - 1 GROUP BY erp_order_id;然后到ERP侧按生产订单查确认数量两个结果做全外连接差异行就是当天必须人工处理的异常单。接口日志只告诉你“调用成功”对账才告诉你“业务成功”。第三件做一个接口断点模拟的重放机制。我的做法是给每个接口留一个手动重发页面并给接口日志表加retry_status字段。模拟场景很简单把下游服务停掉再发一批消息确认日志表里全部落成FAIL然后重启服务只对被拒绝的message_id做重放而不是整批重跑。重放后看ack_at有没有更新同时看ERP侧是否生成了新凭证号。如果凭证号没有变化说明重放的消息被幂等键拦截了这个接口的幂等才算真正做合格。之后每次改接口定义都按这个流程验证一遍清单才配得上叫清单。本文还有配套的精品资源点击获取