简介：一份203页的PPT完整呈现DG美的智能制造中MES与WMS系统协同落地方案，适合制造业信息化规划、供应链管理及智能工厂建设人员学习。内容从芜湖MES需求总体思路切入，梳理制造执行、效率、精细化、品质在线、设备、用户思想、数据互联七大功能模块，并围绕WMS供应商送货、入厂扫描、报检、来料入库、配送上线等全流程展开，同时对PLC互联、AGV集成、机器人融合、OEE与TPM设备管理及HCM/HCS等数据互联机制做了说明。包内包含1个pptx文件（203页），压缩包大小11.06MB，便于直接阅读与二次整理。目前已有74人学习浏览，适合作为制造物流一体化平台方案的参考模板。阅读后可系统掌握MES与WMS集成的业务蓝图、流程节点与关键管控点，为同类项目的需求梳理、方案设计和汇报展示提供直接素材。
1. MES与WMS协同平台：制造和物流的接缝，才是真正的利润漏点
做智能制造项目多年，我见过最典型的翻车现场不是设备宕机，而是 MES 和 WMS 各自跑得飞快，接口一断整条产线停下等料。MES 管的是工单、工序、报工和质检，WMS 管的是收货、上架、拣选和发运，这两个系统在企业里通常分属制造部和物流部，买自不同厂商，数据库结构也完全不一样。于是「高效协同」就卡在了制造与物流的接缝处：原材料从仓库到线边库要人工签单，成品从产线下来要人工录单入库，账实差异全靠月底盘点来擦屁股。这份 PPT 标题所指向的，就是用一套 MES 与 WMS 协同平台，把接缝处的数据流和实物流对齐，让车间要料时仓库已经备好货，产线完工时仓库已经知道该往哪个库区放。适合正在上 MES 或 WMS、却发现两个系统各自为政的中大型制造企业，也适合准备立项做智能制造整体规划的技术负责人。下面这套拆解，是我按自己做过的协同项目总结出来的落地路径，从边界、状态机、数据模型，一直讲到联调踩坑和效果验证。
2. 先划清边界再谈协同：MES 与 WMS 在智能制造里的责任切分
很多项目一开始就错了：项目组拿到需求就画流程图，把 MES 和 WMS 的功能画在一张泳道图上，看上去很协同，实际开发时两个厂商互相等对方改接口。我给这类项目做规划时，第一件事不是画流程，而是先写一份责任切分表，把每个业务动作的唯一负责系统定死，再谈怎么联动。这一章就在讲边界为什么要先定、怎么定，以及边界定完后交接区怎么设计。
2.1 一张责任切分表，消灭 80% 的扯皮
责任切分的逻辑其实很简单：每个业务对象在同一个时间点，只能有一个系统对它负责。物料是「在库」还是「在制」，决定了它是 WMS 的管辖范围还是 MES 的管辖范围；工单是「已下达」还是「执行中」，归属 MES；库位是「可用」还是「冻结」，归属 WMS。按这个原则，我一般先用一张表把核心对象的归属写清楚，再往里面填单据流和状态流。
| 业务对象 | 归属系统 | 关键状态 | 协同触发点 |
|---|---|---|---|
| 原材料库存 | WMS | 收货、上架、可用、冻结 | MES 要料时生成领料申请 |
| 线边仓库存 | MES | 齐套、已消耗、退料 | 从 WMS 收货区转移时过账 |
| 在制品 WIP | MES | 开工、完工、报废 | 报工时同步扣减线边库存 |
| 产成品 | WMS | 待入库、已入库、已发运 | MES 完工报工触发入库指令 |
| 工单 | MES | 下达、开工、完工、关闭 | 工单关闭前校验 WMS 入库数 |
这张表的价值在于把模糊区域显性化。最常见的争议是线边库算谁的——制造部觉得物料出了仓库就该 MES 管，物流部觉得货没消耗完就该 WMS 管。我的处理惯例是：线边库归属 MES，但每一次从 WMS 仓库到线边库的转移，必须走一次「库位转移过账」，两边库存同时变化。物理上物料挪了地方，账面上两个系统各记一笔，谁都不吃亏。
定完责任切分表，再回头做功能蓝图就顺了：MES 不关心仓库里还剩多少货，它只关心线边库够不够用料；WMS 不关心工单进度，它只关心有没有入库指令和出库指令。系统之间的耦合点从十几个砍到只剩四个——领料、入库、批次追溯、盘点差异。
2.2 交接区设计：原材料仓到线边库的配送逻辑
责任切分表定完后，最值得花精力的是交接区。智能制造里常说「料等人」还是「人等料」，「人等料」就是配送逻辑没设计好。原材料仓和线边库之间隔着一个物理搬运过程，这个过程在信息系统里必须有明确的状态节点。
常见做法是引入「配送任务」这个概念，挂在 WMS 里，但由 MES 的工单需求驱动。MES 做完齐套分析，生成一条要料申请，带上工单号、物料编码、需求数量、需求时间；WMS 收到申请后，把它转成配送任务，分配拣货员、库位和搬运设备。任务执行完，WMS 回传「已上架到线边库位」的确认，MES 才把物料状态从「待领用」改成「可用」。
这里最容易犯的错误是让 MES 直接生成 WMS 的拣货单。我在一个项目里见过这种设计，当时 MES 厂商为了省事，把仓库库位表复制了一份放到自己库里，拣货逻辑也在 MES 里做了。结果 WMS 改了库位编码规则，库位编号全变了，MES 里存的旧库位号全部作废，拣货单打出来找不到货。后来改成 MES 只负责「提需求」，WMS 负责「怎么拣、从哪拣、拣完放哪」，这类问题再没出现过。边界不仅是数据边界，也是功能边界，越权做别人的核心逻辑，迟早要还。
2.3 协同主数据：物料、批次、库位与单位换算的映射
协同跑得顺不顺，主数据决定下限。MES 里的物料编码和 WMS 里的物料编码大概率不是同一套，有的企业 MES 用物料号加版本号，WMS 用物料号加供应商代码，不映射清楚，接口联调时会发现同一个物料在两边查出来是两条记录。
我的做法是建一张协同映射表，在中间件或调度层维护，不在某个系统里强行改编码。映射表至少包含四类对象：
第一是物料映射。两边物料编码不一致时，以哪个为准，这个要由数据治理小组拍板，不能由开发自己定。第二是批次映射。MES 里的批次号是生产批次，WMS 里的批次号可能是供应商批次或入库批次，追溯时要把两层批次关联起来，在映射表里存「WMS 批次号 → MES 批次号」的双向关系。第三是库位映射。MES 里的线边库位和 WMS 里的库位编码不一样，协同时要经由映射表翻译。第四是单位换算。MES 按件管理，按 kg 发料，按 pcs 报工的情况非常普遍，换算系数要写进映射表，不能写死在接口代码里。
映射表建好后，要安排一轮主数据清洗。常见问题是同一个物料在 MES 里有三条编码，在 WMS 里有两条，映射表里直接出现一对多。清洗原则是「谁的使用范围大，谁的编码保留」，另一方在映射表里做别名。协同平台上线的第一天，一半的接口报错都来自主数据缺失，这一轮清洗值得做完再做功能联调。
3. 用状态机驱动制造与物流协同：主数据、事务、接口三层设计
边界定完，接下来要做的不是直接写接口，而是先定义协同流程里的状态机。很多项目接口崩，不是因为代码写得差，而是因为状态没有定义清楚，「已提交」和「已完成」在一个系统里是同一个字段的不同取值，在另一个系统里是两套字段。协同平台里的状态机，要把两个系统的状态统一成一套语义，再做映射。
3.1 状态机：从「计划下达」到「完工入库」的六次状态跃迁
我做的协同方案里，核心流程是一条七节点状态链：计划下达 → 齐套确认 → 领料出库 → 工单开工 → 完工报工 → 成品入库 → 工单关闭。每个节点都有明确的触发源和接收方。
计划下达由 ERP 或计划系统触发，MES 接收后生成工单；齐套确认由 MES 检查线边库物料是否足够；领料出库由 MES 发起申请，WMS 执行出库；工单开工表示 MES 开始投料；完工报工表示 MES 产出成品；成品入库由 MES 发出入库指令，WMS 执行收货上架；工单关闭是所有入库数量核对无误后的终态。
这个状态机的关键设计是「单向推进 + 中间可逆」。计划和开工之间可以取消，领料出库后如果发现物料用错，可以做退料回退；但完工入库之后，不允许直接回退到开工状态，只能走返工单。为什么？因为完工入库意味着 WMS 的库存已经增加，直接回退会造成两边账务不一致，必须用一张红字单据冲销。我在设计评审会上反复强调过这条规则，它可以杀掉一大批「为了操作方便而乱跳状态」的需求。
状态机可以用一张表来定义，字段简单直接：当前状态、触发事件、目标状态、动作归属系统、需要调用哪些接口。
| 当前状态 | 触发事件 | 目标状态 | 动作归属系统 |
|---|---|---|---|
| 已下达 | 齐套分析通过 | 已齐套 | MES |
| 已齐套 | 生成领料申请 | 领料中 | MES 发起，WMS 执行 |
| 领料中 | WMS 出库确认 | 已领料 | WMS |
| 已领料 | 产线开工 | 生产中 | MES |
| 生产中 | 完工报工 | 已完工 | MES |
| 已完工 | 入库指令完成 | 已入库 | WMS 执行 |
| 已入库 | 数量核对一致 | 已关闭 | MES 复核 |
把这个表落到代码里，不要用 if-else 堆，用状态机表驱动。事件到了，查表找目标状态和动作，找不到就直接报「非法状态跃迁」，这比任何防御式编码都管用。
3.2 接口实现：MES 调 WMS 的入库指令怎么写
状态机定义好后，接口实现就是翻译工作。下面我用一个「完工入库」的典型交互来演示，MES 完工报工后，调用 WMS 的入库接口。
// MES 侧：完工报工完成后，拼装入库指令并调用 WMS async function notifyWmsInbound(workOrderId) { // 1. 从 MES 本地查询完工数量、物料、批次 const completion = await mesQueryCompletion(workOrderId); // 2. 组装协同平台的统一报文 const inboundRequest = { messageId: genMessageId(), // 全局唯一，用于幂等 sourceSystem: "MES", targetSystem: "WMS", docType: "INBOUND_NOTICE", // 单据类型：入库通知 workOrderId: workOrderId, materialCode: completion.materialCode, batchNo: completion.batchNo, quantity: completion.finishedQty, qtyUnit: "PCS", // 统一用小单位，由映射层换算 targetWarehouse: "FG-01", targetLocation: getDefaultLocation(completion.materialCode), timestamp: new Date().toISOString() }; // 3. 调用 WMS 入库接口，开启超时与重试 const result = await callWmsInbound( inboundRequest, { timeoutMs: 3000, retries: 3, retryDelayMs: 1000 } ); // 4. 记录协同事务表，状态机推进 await saveCoordinationLog(workOrderId, "INBOUND_NOTICE", result); }这段代码的核心在两个地方：messageId 和事务记录。messageId 是幂等键，WMS 收到同一 messageId 的报文，直接返回上一次的处理结果，不能重复入库。如果没有这个字段，接口超时后重试，仓库账上会多出一倍库存。saveCoordinationLog 是把每一次协同写进一张独立的日志表，出了问题不用翻两个系统日志，先查这张表，能省两个小时的排错时间。
调用参数上，timeoutMs 设 3000 毫秒，重试 3 次。这里的经验是：WMS 入库操作在正常负载下 1 秒内能完成，超过 3 秒大概率是网络抖动或 WMS 服务过载，重试比等更靠谱。但如果 WMS 的处理本身超过 10 秒，比如要求打印序列号标签，那就要改成异步回调模式，MES 先记「已提交」，WMS 完成后回调通知。同步还是异步，取决于 WMS 接口的平均响应时间，不要盲目统一。
3.3 事务补偿：接口超时与重试的兜底方案
分布式系统里最难受的就是接口超时。MES 发完入库指令，WMS 没回确认，这笔账算谁的？我的方案是引一张「协同事务表」，每条协同记录带着状态字段，初始值为「已发送」，收到确认后改成「已完成」，超时后变成「待补偿」。
CREATE TABLE co_transaction_log ( message_id VARCHAR(64) PRIMARY KEY, source_system VARCHAR(20) NOT NULL, target_system VARCHAR(20) NOT NULL, doc_type VARCHAR(40) NOT NULL, biz_id VARCHAR(64) NOT NULL, status VARCHAR(20) NOT NULL, -- PENDING/SUCCESS/COMPENSATED/FAILED request_payload JSONB, response_payload JSONB, retry_count INT DEFAULT 0, create_time TIMESTAMP DEFAULT now(), update_time TIMESTAMP DEFAULT now() );补偿任务每 5 分钟扫一次 PENDING 状态的记录，重发超过 3 次还是失败，就转人工。这个逻辑看起来简单，但设置一个底线规则：任何协同记录不允许永远躺在 PENDING 状态里，要么成功，要么失败，要么人工介入。我见过最惨的项目，补偿任务没配告警，PENDING 记录攒了几百条，月底盘点时一次性爆雷。最后拆解下来，才发现是 MES 与 WMS 的服务端时间不同步，回调总是先于发送到达，状态被覆盖了。修好 NTP 时间同步后，问题当场消失。
「时间不同步」这几个字值得单独告诫：所有协同系统必须统一用 NTP 对时，日志时间戳才有可比性。排查跨系统问题，第一步先看时间对不对，第二步再查状态机，这个顺序别反了。
4. 数据模型与字段级设计：一张数据字典打通两个黑匣子
状态机和接口解决了「怎么传」，数据模型解决「传什么、存在哪」。这一章写给那些被 MES 和 WMS 的数据库结构差异搞得头大的工程师。两个系统各自的表和字段不能动，那就建对齐层、映射表和数据字典。数据字典是协同项目最容易偷懒的地方，多数项目写不出好数据字典，接口字段全靠开发时候现问，问完还不写文档。
4.1 两张关键表和一条映射链
协同层核心表就两张：物料映射表和批次关联表。物料映射表解决「同一个物料在两边的编码不一样」的问题，批次关联表解决「同一个批次在两边的批次号不一样」的问题。
物料映射表字段不复杂：内部物料 ID、MES 物料编码、WMS 物料编码、物料名称、计量单位、默认单位换算系数、状态。主键用内部物料 ID，两边的编码都做普通索引。查的时候先查内部物料 ID，再翻译成目标系统编码，杜绝在代码里写死「MES 编码 A 对应 WMS 编码 B」这样的映射逻辑。
批次关联表的字段要多一些：批次关联 ID、MES 批次号、WMS 批次号、物料内部 ID、入库时间、质检状态、当前归属系统。为什么需要这张表？MES 里一个生产批次可能对应 WMS 里的多个入库批次——一批产品分两次入库，这在离散制造业里太常见了。没有这张表，追溯时都不知道 MES 批次去哪查 WMS 记录。
映射链则是一条完整的数据血缘：客户订单 → MES 工单 → 生产批次 → WMS 入库批次 → 库位记录 → 发运单。这条链的价值在质量追溯时体现：客户投诉某批产品有问题，顺着这条链能同时看到生产参数和物流轨迹，两边数据对得上，才能快速圈定不良批次范围。
4.2 数据字典：字段、类型、默认值与来源系统对照表
数据字典是协同项目最重要的交付物，没有之一。做数据字典时，关键不是把每个字段列出来，而是标注「来源系统」和「是否允许映射层修改」。来源系统决定了字段的权威性，防止两边同时维护同一字段导致数据打架。
| 字段名称 | 数据类型 | 所属系统 | 默认值 | 映射规则 | 是否共享 |
|---|---|---|---|---|---|
| work_order_id | varchar(32) | MES | 无 | 直接同步 | 是 |
| material_code | varchar(30) | MES | 无 | 经物料映射表翻译 | 是 |
| batch_no | varchar(40) | MES | 无 | 经批次关联表翻译 | 是 |
| inbound_qty | decimal(14,4) | MES | 0 | 单位换算后同步 | 是 |
| warehouse_code | varchar(20) | WMS | 无 | 经库位映射表翻译 | 是 |
| location_code | varchar(30) | WMS | 无 | 经库位映射表翻译 | 是 |
| stock_status | varchar(20) | WMS | 可用 | 直接同步 | 是 |
| supplier_lot | varchar(40) | WMS | 空 | 仅 WMS 维护 | 否 |
这张表在实际项目里通常有几十行。我特别标了「是否共享」这一列，用来区分共享字段和私有字段。供应商批次号这种只对仓库有意义的字段，MES 不需要它参与排产，就标为仅 WMS 维护。别把所有字段都同步——同步的字段越多，出错面越大。协同平台的通信越短，越稳定，这是我一直坚持的瘦事件原则：只传对方系统做决策真正需要的字段，其余一概不传。
4.3 按单追溯与批次追溯：质量回溯的场景推演
数据模型设计得好不好，要看追溯场景能不能跑通。我习惯在项目交付前，拿一个真实批次做一次「从客户投诉到供应商」的追溯推演，走不通就回头改模型。
场景是这样的：客户投诉某批次电机外壳尺寸超差。需要回答三个问题：这批电机是哪个工单生产的？用了哪个供应商的哪批原料？成品发给了哪些客户？
按单追溯的查询逻辑是：MES 工单号 → 生产批次 → 完工入库记录 → WMS 入库批次 → 库位记录 → 发运单号。如果协同层没有批次关联表，查询就会断在「完工入库记录」这一环：MES 只知道生产批次，WMS 只认入库批次，两边对不上，追溯就卡住了。批次关联表的存在，让查询可以直接从 MES 批次跳到 WMS 入库批次，再继续向后查。
正向看这个逻辑似乎不难，但实际业务里比这复杂。同一个生产批次可能跨多个 WMS 入库批次，这说明产成品分批次入库了；同一个入库批次可能对应多个生产批次，说明仓库把不同工单的成品混放在了一起。混放本身是正常的，但如果 WMS 在收货时没有做批次拆解，追溯时会级联放大问题范围。所以数据模型里还要加一道「批次拆分记录」，每次混装都要留痕，否则质量问题圈定的范围是一个批次，而不是其中某一部分。
这一章最后补一句关于主数据治理的话：数据字典建完后，要拉 MES 和 WMS 两边的开发和业务一起评审，评审通过后再动手联调。数据层评审省 100 个问题，比事后改数据模型省太多时间。
5. MES 与 WMS 联调五大踩坑：现象、原因、解决方案
做协同平台，联调阶段才是真正的「照妖镜」。我在几个项目里攒下的踩坑经验，不少是拿上线后的加班换来的。这章把最典型的五类问题列出来，每一条都是「现象 → 原因 → 解决」三段式，给后面做同类型项目的同行一个参照。
5.1 上线第一天，原材料仓与线边库存差异 80 笔
现象：系统上线的第一个夜班结束，MES 里线边库的账面库存和 WMS 里转移到线边库的累计出库数对不上，差异单据 80 多笔。
原因：两个系统的盘点节奏不一致。WMS 每天凌晨对仓库做动态盘点，MES 只在工单齐套校验时读取一次线边库存，两个动作间隔内，领料和退料照常发生，盘点结果互相覆盖。
解决：统一盘点窗口。把 WMS 的盘点动作和 MES 的齐套校验放在同一时间点，盘点期间锁定线边库的出入库操作。锁定期限在系统里做成了配置项，默认 30 分钟，夜班 00:30 到 01:00 执行，两边系统在此时段内不允许做领退料操作。这个方案上线后，每天的差异单据降到了 5 笔以内，剩下的差异基本是人为操作失误。
5.2 成品完工后，WMS 一直收不到 MES 的入库指令
现象：MES 完工报工成功，状态也推进到了「已完工」，但 WMS 侧没有生成任何入库任务，成品在产线末端堆积。
原因：MES 完工报工事务和入库指令发送不在同一个事务里。报工成功但消息发送失败时，MES 没有做事务回滚，导致状态机跳过了通知 WMS 的步骤。
解决：在协同事务表里补一条回扫任务，扫描「已完工但无入库指令」的工单，自动补发。回扫周期设为 2 分钟一次，这个任务不能依赖消息队列的重试机制，因为队列本身可能堆积。补发时要带幂等键，避免 WMS 重复入库。这条经验后来被我做进了所有协同项目的标准配置，回扫任务在项目里就叫「后悔药任务」，专治各种漏发和忘发。
5.3 批次号在 MES 是全局唯一，在 WMS 变成库位唯一
现象：WMS 里同一个批次号出现在多个库位，MES 查批次追踪时发现一个批次对应多张完工入库单，数据看板上的批次追溯链路乱了。
原因：WMS 允许同批次产品分多次入库到不同库位，批次号自动带上了库位后缀。MES 生成的批次号是生产维度，WMS 管理的是库位维度，两边批次号的「唯一性范围」假设不同。
解决：批次关联表从一对多改成多对多，增加库位字段。EAS 侧查批时先按 WMS 批次号拆开再合并展示。这个坑的教训是：任何单独属于一个系统的规则，另一个系统都不能想当然地复用。做接口评审时，必须把「唯一性范围」列成单独议题逐项确认。
5.4 单位不一致：MES 按 kg 发料，WMS 默认存 pcs
现象：某条产线用同一物料生产不同型号产品，MES 按重量 kg 记录发料，WMS 按件数 pcs 管理库存。接口联调时，MES 下发 500kg 原材料，WMS 收到后当作 500 件处理，账实严重偏差。
原因：MES 这边的物料单位是出厂包装规格换算后的，WMS 那边的物料单位是仓库管理的物理最小单位，两个系统没有约定标准单位。
解决：协同层统一换算。标准单位定成 pcs，所有跨系统报文必须先换算成标准单位再发送。换算系数存在物料映射表里，不同供应商的同一物料如果单件重量不同，按供应商维度配置换算系数。这条改完加了校验：接口报文里必须带上 qtyUnit 字段，接收方校验单位与标准单位不符直接拒绝，宁可不处理也不存错账。
5.5 首次盘点差异大：WMS 账实相符，但 MES 在制数对不上
现象：月底盘点，WMS 的库存账实相符，但 MES 的在制品数量和对不上，差异集中在跨月生产的工单上。
原因：MES 的在制品数量是按「领料数 - 完工数」倒算的，但退料、报废、返工这三类操作没有计入。跨月工单跨越了多次盘点周期，差异被不断累积放大。
解决：在 MES 侧增加在制品冲减流程。报废品必须先做报废确认再扣减在制，退料必须关联原领料单，补料要带补料原因。这套流程上线后，在制品差异率从 7% 降到了 1.5% 左右。如果盘点后差异仍然存在，先查报废单据有没有录入，占差异原因的比例通常最高。
6. 验证协同平台是否真正落地：三个可量化的判断办法
方案讲得再好，最终要回答一个问题：协同平台到底有没有真正落地？我评估一个 MES 与 WMS 协同项目，不看汇报 PPT，只看三个指标。
第一个指标是单据流转时效：从 MES 完工报工到 WMS 完成入库上架，平均耗时是否在 10 分钟以内，甚至 5 分钟内。流转时效查协同事务表，看 create_time 到 update_time 的差值分布。如果链路里有一堆超过 30 分钟的记录，说明中间有卡点，常见是 WMS 收货人员没有及时确认，或接口重试堆积。这个指标我会让它进日常看板，不查不知道，一查吓一跳。
第二个指标是账实相符率：周维度拉一次差异单据数，协同上线两个月后，差异单据要控制在总单据量的 0.5% 以内。如果还在 2% 以上，别急着优化算法，先回去查流程有没有按状态机执行，手工补单是不是还在大量发生。手工补单是协同平台的头号杀手，每多一张手工单，就有一处接口被绕开，系统价值就少一分。
第三个指标是异常单据的闭环率：PENDING 或 FAILED 状态的记录，24 小时内闭环（成功、补偿或转人工）的比例。闭环率低于 95% 说明补单机制没起作用，问题单据在「等」而不是「处理」。
给一个最直接的检查脚本，用一条 SQL 就能大概估算协同健康度，它统计异常状态的分布：
SELECT date(create_time) AS day, status, count(*) AS cnt FROM co_transaction_log WHERE doc_type IN ('INBOUND_NOTICE','PICK_REQ','TRANSFER_REQ') AND create_time >= now() - interval '10 day' GROUP BY date(create_time), status ORDER BY day, status;这个查询看起来平平无奇，但它能看出协同平台最底层的问题：如果 PENDING 和 FAILED 的数量随日期增长呈上升趋势，那一定不是偶发故障，是某个环节在持续产生垃圾数据；如果三天内某类单据的 PENDING 数量超过两百条，先看是不是 WMS 接口服务发布了新版本，改了报文格式却没同步更新消费方。我习惯在每个周四拉一次这张表，复盘当周的协同质量，这个习惯已经保持了好几年。
做 MES 与 WMS 协同项目，最深的体会是「先立规矩再写代码」永远比「先跑通再说」走得远。数据字典和状态机是第一天就要定的规矩，接口是后面一个月的翻译活。绝大多数项目翻车在边界不清、状态不明、补偿缺失这三个点，而不是算法不够先进。希望这些经验能帮你少走几个弯路，把制造与物流的接缝真正缝严。希望帮到你。
本文还有配套的精品资源，点击获取
