企业官网建设流程全解析

简介：本资源是天心ERP 9.0版本中面向制造企业的核心操作指南，专为MRP制程生产模块的实施人员、系统管理员及一线业务用户设计，解决生产计划排程、工序流转、物料齐套分析与制程数据闭环管理等关键场景的操作盲区。压缩包内含1个完整PDF手册（17.75MB），全面覆盖系统介绍、主流程图解、制程生产与进销存/财务等模块的集成关系、基本资料建置规范、BOM与工艺路线维护、工单派工与报工、在制品追踪等实操章节，目录结构清晰，含501页详细图文说明与界面指引。手册由天心软件科技（珠海）有限公司官方编写，严格遵循APICS MRPII标准，融合JIT、TQM等先进管理理念，支持C/S架构下二十多个子系统的灵活组合应用。目前已有159人学习下载，适合希望深入理解天心ERP制程逻辑、开展上线准备或进行内部培训的企业用户。

1. 天心ERP 9.0 Sunlike+ERP MRP制程生产操作手册：不是“翻页PDF”，而是产线调度员的实时作战地图

你有没有遇到过这种场景：车间报工卡在“工序委外确认”环节，系统显示BOM版本号不匹配，但工艺员坚称昨天刚在Sunlike+ERP里更新过；或者MRP重排程后，采购建议单突然多出37条紧急缺料预警，而仓库台账明明写着库存充足——查到最后，发现是制程路线中某道热处理工序的“标准工时”被误设为0.05小时（实际需4.2小时），导致系统把整条产线排程压缩进半天内。这不是数据录入错误，而是对天心ERP 9.0中MRP与制程生产模块耦合逻辑的理解断层。本手册不是教你怎么点菜单，而是拆解Sunlike+ERP如何把一张BOM表、一条制程路线、一个工单状态机，实时翻译成产线工人手里的报工终端指令、计划员屏幕上的甘特图波动、以及财务端的成本归集路径。它面向的是刚接手老系统运维的工程师、需要跨模块协同的计划主管，以及正在把传统纸质制程卡迁移到天心ERP的制造企业实施顾问。核心价值就一条：让MRP不再是个黑匣子，让制程生产不再是IT部门的“玄学”。

2. 理解天心ERP 9.0中MRP与制程生产的耦合机制：为什么“重排程”会触发工单状态重置

天心ERP 9.0的MRP引擎（Sunlike+ERP内核）不是独立运行的计算模块，它与制程生产模块通过三张关键表深度绑定：PROD_ROUTE（制程路线主表）、ROUTE_STEP（工序步骤明细）、WORKORDER_DETAIL（工单工序明细）。理解这三者的联动关系，是避免后续所有“系统算得不对”的前提。

2.1 制程路线（PROD_ROUTE）：MRP的物理约束锚点

制程路线不是简单的工序列表，它是MRP计算时的时间-资源-物料三维约束源。例如，某电机外壳的制程路线包含：下料→冲压→CNC精加工→阳极氧化→组装。其中：

• ROUTE_STEP中每道工序必须关联RESOURCE_ID（设备/班组编码），MRP重排程时会校验该资源在指定时段是否已被其他工单占用；
• 每道工序的STD_TIME（标准工时）直接影响MRP输出的“最早开工日”和“最晚完工日”；
• 关键字段IS_CRITICAL（是否关键工序）决定MRP是否允许跳过该工序进行并行排程。

提示：天心ERP 9.0默认将IS_CRITICAL=1的工序设为“不可压缩节点”，若此处误设，会导致MRP强行拉长整体交期，即使实际产线可并行作业。

2.2 工单与制程路线的动态绑定：WORKORDER_DETAIL的生成逻辑

当销售订单触发MRP运算后，系统并非直接生成工单，而是先生成WORKORDER_HEADER（工单头），再根据PROD_ROUTE自动填充WORKORDER_DETAIL（工单工序明细）。这个过程的关键在于ROUTE_STEP中的SEQ_NO（工序序号）与WORKORDER_DETAIL中STEP_SEQ的严格对应。常见错误是：

• 在ROUTE_STEP中新增一道返工工序（如“返工打磨”），但未调整其SEQ_NO，导致它被插入到“CNC精加工”之前，系统误判为前置工序，从而将整条产线排程前移；
• WORKORDER_DETAIL中PLAN_START_DATE由MRP根据ROUTE_STEP.STD_TIME和资源负荷反向推算，而非人工填写——这意味着修改工单头的“计划开工日”不会自动重算各工序时间，必须手动触发“重排程”。

2.3 MRP重排程对制程生产状态的级联影响

在天心ERP 9.0中，“重排程”操作会触发以下强制动作：

1. 清空所有已生成但未报工的WORKORDER_DETAIL记录；
2. 根据最新BOM版本、库存快照、在途采购单，重新计算ROUTE_STEP中每道工序的PLAN_START_DATE和PLAN_END_DATE；
3. 将工单状态从“已下达”重置为“已计划”，要求计划员二次审核工序时间；
4. 若ROUTE_STEP中某工序的RESOURCE_ID在新排程时段已被占用，系统不会自动替换资源，而是标记该工单为“资源冲突”，需人工干预。

这个机制解释了为什么车间抱怨“MRP一重跑，工单就变红”。它不是Bug，而是设计使然：天心ERP 9.0将制程生产的确定性建立在MRP结果的绝对权威上，任何手工调整都必须经由MRP引擎重新验证。

3. 在Sunlike+ERP中配置MRP制程生产参数：三个必调字段与两个隐藏开关

天心ERP 9.0的MRP制程生产模块默认参数无法直接支撑中小制造企业的柔性排程需求。以下是我在某汽车零部件厂落地时，必须调整的5个核心参数（均位于Sunlike+ERP后台【系统管理】→【参数设置】→【MRP参数】页签）：

3.1MRP_CALCULATION_MODE：选择“按工序驱动”而非“按工单驱动”

这是最易被忽略的开关。默认值为ORDER_BASED（工单驱动），即MRP仅计算工单级开工/完工时间，工序时间由人工分配。改为STEP_BASED（工序驱动）后，MRP会逐条校验ROUTE_STEP中的STD_TIME与资源负荷，生成精确到小时的工序级排程。

# 在Sunlike+ERP数据库中执行（需DBA权限） UPDATE ERP_SYS_PARAMS SET PARAM_VALUE = 'STEP_BASED' WHERE PARAM_CODE = 'MRP_CALCULATION_MODE'; -- 执行后需重启应用服务，否则前端参数页签不生效

参数说明：STEP_BASED模式下，MRP运算耗时增加约40%，但可避免80%以上的“工单能排、工序排不了”问题。适用于工序复杂度高、设备专用性强的企业。

3.2CRITICAL_PATH_BUFFER：为关键工序设置浮动缓冲时间

该参数定义关键工序（IS_CRITICAL=1）的计划时间浮动阈值，单位为小时。默认值为0，意味着关键工序时间不可压缩。若设为2.0，则MRP在重排程时，允许将关键工序的PLAN_START_DATE最多提前2小时或延后2小时，以适配突发插单。

注意：此参数仅对IS_CRITICAL=1的工序生效，且缓冲时间不计入标准成本核算——它纯粹是排程柔性的“后悔药”，不影响财务端。

3.3WORKORDER_STATUS_SYNC：控制工单状态与MRP的同步粒度

默认值为HEADER_ONLY（仅头信息同步），即MRP只更新工单头的PLAN_START_DATE。改为HEADER_AND_DETAIL后，每次重排程都会强制刷新WORKORDER_DETAIL中所有工序的PLAN_START_DATE和PLAN_END_DATE，确保车间报工终端看到的时间与MRP最新结果一致。

-- 验证当前设置 SELECT PARAM_VALUE FROM ERP_SYS_PARAMS WHERE PARAM_CODE = 'WORKORDER_STATUS_SYNC'; -- 返回 'HEADER_AND_DETAIL' 表示已启用工序级同步

3.4 隐藏开关1：启用“工序替代资源”功能

该功能在Sunlike+ERP前端界面无入口，需在数据库中开启：

UPDATE ERP_SYS_PARAMS SET PARAM_VALUE = 'Y' WHERE PARAM_CODE = 'ENABLE_ROUTE_RESOURCE_SUBSTITUTION';

开启后，在ROUTE_STEP中可为同一工序配置多个RESOURCE_ID（如CNC精加工既可用设备A，也可用设备B），MRP重排程时自动选择空闲率最高的资源。这是解决“单台关键设备故障导致全线停产”的技术底座。

3.5 隐藏开关2：关闭“BOM版本强校验”

对于频繁改模的注塑件企业，BOM版本日更3次是常态。默认开启的BOM_VERSION_STRICT_CHECK会导致MRP因版本不匹配直接终止运算。临时关闭（设为N）可让MRP降级使用最新版BOM，但需配合每日凌晨的BOM快照备份机制，避免追溯失真。

4. 制程生产日常操作避坑指南：5条血泪经验换来的排查清单

在某家电代工厂的产线切换项目中，我们曾因以下问题导致连续3天MRP重排程失败。这些不是文档里写的“注意事项”，而是现场翻车后写进手册的硬核排查项：

4.1 现象：MRP重排程后，某工单的“阳极氧化”工序PLAN_END_DATE比“组装”工序还晚2天

原因：ROUTE_STEP中“阳极氧化”工序的RESOURCE_ID指向一个已停用的旧设备编码（如EQP_OLD_001），而该设备在资源主数据中状态为“停用”，但MRP引擎未做状态校验，仍将其纳入排程池，导致计算出的结束时间严重失真。
解决：在重排程前，执行SQL检查所有工序关联的资源状态：

SELECT rs.STEP_NAME, rs.RESOURCE_ID, r.STATUS FROM ROUTE_STEP rs JOIN RESOURCE_MASTER r ON rs.RESOURCE_ID = r.RESOURCE_ID WHERE r.STATUS = 'DISABLED'; -- 将查询结果中的`RESOURCE_ID`全部更新为有效设备

4.2 现象：车间报工时，“返工打磨”工序始终无法提交，系统提示“工单未下达”

原因：该工序在ROUTE_STEP中SEQ_NO=999（人为设为末位），但WORKORDER_DETAIL中对应的STEP_SEQ为1，因SEQ_NO与STEP_SEQ不匹配，系统拒绝识别此为合法工序。
解决：修复ROUTE_STEP的SEQ_NO连续性，并执行工单重生成：

-- 修正工序序号（以制程路线ID=123为例） UPDATE ROUTE_STEP SET SEQ_NO = ROW_NUMBER() OVER (ORDER BY STEP_NAME) WHERE ROUTE_ID = 123; -- 再在Sunlike+ERP前端对工单执行“重新生成工序明细”

4.3 现象：MRP运算日志显示“BOM循环引用”，但BOM树状图中无环路

原因：某子件在BOM中被设为“虚拟件”，其自身又作为父件出现在另一层级BOM中，形成逻辑环路。天心ERP 9.0的BOM校验器对虚拟件的环路检测存在盲区。
解决：导出全量BOM数据，用Python脚本检测环路（关键逻辑）：

def detect_bom_cycle(bom_data): # bom_data: {parent: [child1, child2, ...]} visited = set() rec_stack = set() def dfs(node): visited.add(node) rec_stack.add(node) for child in bom_data.get(node, []): if child not in visited: if dfs(child): return True elif child in rec_stack: # 发现环路 return True rec_stack.remove(node) return False for node in bom_data: if node not in visited: if dfs(node): return True return False

4.4 现象：采购建议单中某物料显示“需求数量=0”，但工单明确需要该物料

原因：该物料在ROUTE_STEP中被设为“非消耗性”（IS_CONSUMABLE=N），MRP默认不将其纳入物料需求计算。
解决：在ROUTE_STEP中将IS_CONSUMABLE字段更新为Y，或在MRP参数中启用INCLUDE_NON_CONSUMABLE_IN_MRP（需联系天心技术支持开通）。

4.5 现象：重排程后，工单状态变为“已取消”，但无任何操作记录

原因：MRP引擎检测到该工单关联的制程路线中，某道工序的STD_TIME为空（NULL），触发安全熔断机制，自动取消工单。
解决：批量检查空工时：

SELECT wo.WORKORDER_NO, rs.STEP_NAME FROM WORKORDER_HEADER wo JOIN WORKORDER_DETAIL wd ON wo.WORKORDER_ID = wd.WORKORDER_ID JOIN ROUTE_STEP rs ON wd.ROUTE_STEP_ID = rs.ROUTE_STEP_ID WHERE rs.STD_TIME IS NULL OR rs.STD_TIME = 0;

5. 验证MRP制程生产配置正确性的三步法：从数据流到产线终端

配置完参数、修复完坑，不能只信系统日志。我坚持用以下三步交叉验证，确保天心ERP 9.0的MRP制程生产模块真正“活”在产线上：

5.1 第一步：逆向追踪MRP数据流（数据库层）

选取一个典型工单（如WO-2024-08876），在数据库中执行三连查：

1. 查MRP运算输入：SELECT * FROM MRP_DEMAND WHERE WORKORDER_NO = 'WO-2024-08876'—— 确认需求来源（销售订单/预测单）和数量；
2. 查制程路线绑定：SELECT rs.STEP_NAME, rs.STD_TIME, rs.RESOURCE_ID FROM ROUTE_STEP rs JOIN WORKORDER_DETAIL wd ON rs.ROUTE_STEP_ID = wd.ROUTE_STEP_ID WHERE wd.WORKORDER_NO = 'WO-2024-08876'—— 确认工序、工时、资源三者匹配；
3. 查排程结果：SELECT STEP_SEQ, PLAN_START_DATE, PLAN_END_DATE FROM WORKORDER_DETAIL WHERE WORKORDER_NO = 'WO-2024-08876' ORDER BY STEP_SEQ—— 确认时间逻辑自洽（后工序PLAN_START_DATE≥ 前工序PLAN_END_DATE）。

提示：若第3步中出现时间倒挂，说明ROUTE_STEP.STD_TIME或资源负荷数据异常，需回溯第2步。

5.2 第二步：模拟车间报工终端（前端层）

登录Sunlike+ERP的移动报工APP（或PC端报工界面），用测试账号执行：

• 扫描工单二维码，进入“工序报工”页；
• 逐道工序点击“开始”，观察系统自动填充的START_TIME是否与WORKORDER_DETAIL.PLAN_START_DATE一致；
• 在“阳极氧化”工序点击“暂停”，再点击“恢复”，检查PLAN_END_DATE是否自动顺延（验证缓冲时间生效）；
• 故意在“CNC精加工”工序输入超时工时（如标准2小时，输入5小时），观察系统是否弹出“超时预警”并锁定提交（验证工时校验开关）。

这一步必须真人操作，因为天心ERP 9.0的报工逻辑有前端JavaScript校验，数据库查不到的逻辑在这里暴露。

5.3 第三步：穿透到成本归集（财务层）

MRP制程生产的终极价值是成本精准。在财务模块中，打开该工单的“成本明细表”，重点核对：

• “人工费”是否按ROUTE_STEP.STD_TIME × 工时费率计算，而非按报工实际工时；
• “设备折旧”是否按ROUTE_STEP.RESOURCE_ID关联的设备折旧率分摊；
• “物料耗用”是否与WORKORDER_DETAIL中工序级BOM展开完全一致。

若发现成本归集错位，90%概率是ROUTE_STEP中IS_CRITICAL或IS_CONSUMABLE字段设置错误，需立即修正并重跑MRP。

我带过的每个项目，都在上线前用这三步法跑满72小时压力测试——不是测系统崩不崩，而是测数据流在MRP、制程、报工、财务四个模块间是否“呼吸同频”。有一次，我们在第三步发现成本中“模具费”多计了3倍，追查发现是ROUTE_STEP中一道试模工序被误标为IS_CRITICAL=1，导致MRP将其费用全额分摊到当批所有产品。这种坑，只有穿透到财务层才能看见。希望帮到你。

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