企业官网建设流程全解析

简介：数夫ERP-F19计划管理操作手册是一份面向家具制造企业生产计划岗位与ERP实施人员的实用说明，重点解决生产排产方式多样、计划追踪困难和成本控制不足等常见问题。压缩包内含1个PDF文件，文件大小约1.45MB，内容按系统简介、生产组合方式、预排方式、自动排程、BOM维护、临时协调等模块组织，结构清晰。手册具体讲解了套件拆分成分件排产、直接按下单内容排产，以及拖动式、填充式和自动排程等操作，并说明如何自动推算生产制程前置天数、按制令维护BOM、处理自制与托外临时协调，甚至将订单作为制令进行管理，能够帮助读者快速上手并优化排产流程。目前已有338人浏览学习，说明这份操作手册对计划管理模块的学习者具有较高参考价值。

1. 把计划管理当作排产中枢：F19计划模块解决什么，哪些岗位必须会

数夫ERP-F19是家居制造企业常用的资源计划系统，F19通常指面向家具行业的生产制造版本主线。这里的计划管理不是简单做个排产表，而是把销售订单、物料清单、库存、产能、采购周期整合成一个可执行的生产指令中枢。很多企业上了ERP之后计划模块却用不起来，原因不是软件不行，而是把计划管理理解成了订单登记和手工排产，没有让系统真正参与运算。

我接触过的家居厂里，计划员最头疼的几件事：紧急订单插单后不知道哪些原材料会缺、车间按经验排产结果五金件不齐套、采购下单时间永远比生产需求晚一个周期。F19计划管理的价值就在于把这些散落在Excel里的判断逻辑固化下来，由系统统一计算净需求并给出建议计划量。适合使用这套模块的岗位很明确：计划员、物控员、生产主管和采购跟单，至少这四类人要共用一套计划口径，否则系统跑出来的计划没人认。

2. 上手必会的计划基础：物料档案、BOM与工作日历的三项底层配置

计划模块跑得准不准，七成取决于基础资料干不干净。很多上线项目在计划阶段翻车，都是因为物料属性没维护全、BOM版本混乱、工作日历和实际排班对不上。这三项不是实施顾问帮忙配一次就结束的，需要计划员自己掌握判断口径。

2.1 物料属性：自制、采购与委外三个口径决定计划走向

F19计划运算的第一步是识别物料属性，这决定了需求往下传递的方式。以家居厂常见的板式家具为例：板材、封边带、五金件通常是采购件；柜体、门板这类在厂内加工的属于自制件；部分需要外协做油漆或封边的半成品是委外件。同一个物料如果属性配错，MRP运算结果会完全偏离实际。

物料属性的设置位置一般在「基础资料-物料档案-计划属性」页签，需要重点确认的字段包括：供应类型、默认供应商、提前期、最小订货量、安全库存。供应类型是核心中的核心，系统自动生成计划工单还是采购申请完全依赖这个字段。

我一般会建议物控员每月抽查一次物料属性档案，重点看新录入的物料有没有漏配供应类型和提前期。实际项目里因为新物料复制老物料导致属性带错的情况非常普遍，一个柜体被配成采购件，系统就会漏掉一条产线任务。

2.2 BOM版本：计划展开时最容易被忽略的生效日期

BOM是计划展开的核心依据。F19里BOM支持多版本管理，但很多计划员只在录入的时候看一眼，很少关注生效日期和审核状态。这两个字段直接影响MRP运算时用哪个版本的物料清单，一旦旧版本没失效，运算结果就会把已淘汰的物料需求算出来。

维护BOM时的建议操作顺序是：先建立新版本并填写生效日期，提交审核通过后再将旧版本失效。如果反过来操作，中间会有一段空窗期，期间跑出来的计划缺少新物料需求。还有一个实操细节：BOM里每个子项都有「基数」和「损耗率」两个字段，板材类建议设置1%到3%的损耗率，五金件通常设为0。

提示：F19计划运算默认只抓取审核通过且生效日期在运算日期范围内的BOM版本。排查计划漏算时，优先检查BOM是否处于已审核状态。

2.3 工作日历与产能参数：计划排程的时间基准

工作日历决定了计划开工日期和完工日期的计算基准。家居厂常见的情况是周末不生产但周一要出货，如果日历里周六日全部标为工作日，系统排出的完工日期会偏晚；反过来如果忘记把旺季加班日标为工作日，排期又会偏紧。

F19工作日历的维护入口通常在「基础设置-工厂日历」，建议按车间维度分别维护。开料车间和包装车间可能执行不同的加班安排，共用一套日历会导致计划精度下降。日历维护至少提前一个月更新，并且要覆盖到每个生产工作日。

产能参数这块，我建议先按「车间日标准产能」配置，后期再细化到资源或产线。不要一开始就追求设备级排程，家居制造的计划颗粒度做到车间加产线足够支撑大部分企业，过细的产能模型维护成本高且数据难以保持准确。

3. 从订单到计划：需求收集与计划编制的主流程拆解

基础资料就位之后，计划模块的日常操作才真正开始。计划编制的输入源不是只有一个销售订单，而是销售订单、预测订单、补货需求等多个来源的合并结果。这一章把从需求收集到计划下达的完整路径拆开讲清楚。

3.1 需求来源：销售订单与预测订单的合并逻辑

F19计划管理模块的需求来源包括三类：已审核的销售订单、预测订单、安全库存补货需求。销售订单是硬需求，预测订单是软需求，二者之间需要有一个冲减逻辑。常见做法是用预测覆盖未来四到八周的需求，销售订单确认后自动冲减对应预测量，避免重复计算需求。

我见过不少项目在这一步出问题：预测订单和销售订单同时参与运算又没有设置冲减关系，导致MRP运算出来物料需求翻倍，采购下了大量不必要的订单。F19里这个冲减逻辑通常称为「需求合并」或「ATP冲减」，在计划方案参数里需要明确选择按「订单优先」还是「预测优先」。

如果是订单优先策略，系统会先计算销售订单覆盖范围内剩余的预测份额，超出部分才生成物料需求。计划员每天上班的第一个操作应该是在计划工作台刷新未关闭的销售订单范围，确保新增订单已经纳入需求池。

3.2 编制生产计划：按订单批量还是按库存策略

需求收集完成后，需要决定生产计划的组织方式。家居行业主要有两种模式：面向订单生产MTO和面向库存生产MTS。定制家具企业以MTO为主，标准柜类或常规板材可以考虑MTS。F19计划模块通常支持在「计划策略」字段设置物料级或订单级的计划方式。

MTO模式下，计划员需要维护销售订单的交付日期，系统根据BOM和提前期倒推各车间开工日期。MTS模式下，计划员要关注的是安全库存阈值，系统根据库存低于安全库存触发的净需求生成补货工单。两种模式在同一个工厂经常并存，比如门板走MTO而标准板材走MTS，这在F19里是可以按物料分类分别设置的。

这里有一个实操经验：新上线阶段尽量先统一走MTO，把订单交付数据维护规范后再引入MTS。上来就混合模式，计划员容易分不清某个需求到底是订单带动还是补库带动，对账时很难追溯。

3.3 计划下达与工单拆分：F19里常见拆分规则

计划运算结果经过计划员确认后，下一步是下达。自制件下达为生产工单，采购件下达为采购申请，委外件下达为委外工单。下达之前要检查一个关键字段：需求数量是否超过车间批量上限，超出的需要拆分。

F19里的工单拆分有两种方式：按数量拆分和按交期拆分。按数量拆分适用于产量大、需要分配到多条产线的情况；按交期拆分适用于同一订单分批交付的情况。拆分后工单号会自动带后缀，生产报工和成本核算都会按拆分后的工单记录，所以拆分前一定要确认拆分依据合理，拆错合并非常麻烦。

计划下达前用下面这条SQL查询可用量非常常用，可以快速判断哪些物料已经不足，避免下达后才发现缺料：

-- 查询关键物料的可用量与在途量（按F19常见数据结构整理） SELECT m.item_code AS 物料编码, m.item_name AS 物料名称, (SELECT IFNULL(SUM(s.onhand_qty),0) FROM inv_stock s WHERE s.item_id = m.item_id AND s.warehouse_id = :计划仓库 ) AS 库存总量, (SELECT IFNULL(SUM(a.allo_qty),0) FROM inv_allocation a WHERE a.item_id = m.item_id AND a.order_type = 'MO' ) AS 已分配量, (SELECT IFNULL(SUM(po.remain_qty),0) FROM po_order po WHERE po.item_id = m.item_id AND po.status IN ('确认','在途') ) AS 采购在途量, (库存总量 - 已分配量 + 采购在途量) AS 可用量 FROM item_master m WHERE m.item_code IN (:物料1, :物料2, :物料3) AND m.delete_flag = '0';

这段SQL的逻辑是：库存总量减去已被生产工单分配的数量，再加上还没到货的采购在途量，得到当前真正可以用于新计划的数量。已分配量这张表是关键，很多计划员只查库存总量导致误判物料够用，实际上那些库存可能早被其他工单预定了。remain_qty是采购单还没收完的数量，不代表全部订单金额，只是剩余未交部分。

计划下达的频率建议每天一次，选择在上午十点前完成，这样采购和生产都能尽早看到当天的任务变化。如果一天运算多次，工单频繁增删反而让车间无所适从。

4. MRP运算参数与运算结果处理：决定计划质量的关键开关

F19计划管理模块的核心引擎是MRP物料需求计划运算。同样一套基础资料，参数设置不同，运算结果可能差异巨大。这一章聚焦几个决定运算质量的关键参数，以及运算完成后如何处理系统给出的建议结果。

4.1 运算参数：提前期、安全库存、批量规则的设置口径

提前期字段不能拍脑袋填。采购提前期应该等于供应商正常交期加一天的缓冲天数，生产提前期等于从投料开料到完工入库的标准周期。很多企业填提前期的时候填的是理想值，没有考虑供应商排产周期和车间产能波动，跑出来的计划自然是理想化计划，执行时天天插单。

安全库存有按数量设置和按天数设置两种口径。按天数设置比按数量更符合家居行业的实际：原材料的安全库存天数等于采购提前期加一到两天覆盖波动；成品安全库存天数则根据销售预测误差率来确定。我通常建议五金件类安全库存设三到五天的用量，板材类由于仓库占空间大，设一到两天用量即可。

批量规则直接影响采购或生产的批量大小。常见的选项有直接批量、固定批量和周期批量。直接批量适合定制化程度高的物料，需求多少就下单多少；固定批量适合板材这类有标准包装和采购起订量的物料；周期批量适合需求相对稳定的常规物料，例如按月汇总下单。

4.2 运算过程：F19从成品到原材料的展开逻辑

MRP运算的逻辑是从成品需求开始，逐层向下展开BOM。第一层计算成品对应的半成品需求，第二层根据半成品的BOM展开到原材料需求，每一层都要单独跑一遍净需求计算。这个展开逻辑决定了计划员查看运算结果时的检查顺序。

F19的MRP运算过程可以用下面这段逻辑理解：

# MRP逐层展开逻辑（伪代码，用于理解F19运算过程） 需求队列 = 获取已确认的销售订单+预测订单净需求 while 需求队列不为空: 当前物料 = 需求队列.pop() # 毛需求 = 上层需求数量(已按BOM比例换算) 毛需求 = 当前物料.需求数量 × BOM用量系数 # 净需求 = 毛需求 - 可用库存 - 在途 + 安全库存 可用量 = 现有库存 - 已分配量 + 在途采购量 + 在制工单余量 净需求 = max(0, 毛需求 - 可用量 + 安全库存) if 净需求 > 0: # 按批量规则修正 计划下达量 = 应用批量规则(净需求) # 按提前期倒排：完工日 - 提前期 = 开工日 计划开工日 = 需求日期 - 当前物料.提前期 if 当前物料是自制件: 生成建议生产工单 # 继续向下展开半成品需求 for 子项 in BOM[当前物料]: 需求队列.push(子项, 需求量=计划下达量×子项用量) elif 当前物料是采购件: 生成采购申请建议 # 采购件不再向下展开

这段逻辑里值得注意三个点。第一是「已分配量」的扣减逻辑，凡是已经下达给生产工单的库存都不能重复计算。第二是「在制工单余量」的纳入，如果一个工单已经投产但还没完工入库，其剩余未完工数量可以冲减毛需求，否则会重复计算需求。第三是批量规则修正，净需求不等于计划下达量，必须经过批量取整。

4.3 运算结果：建议计划量、例外信息与计划员的处理顺序

MRP运算完成后的结果界面通常分为几个区块：建议生产工单、建议采购申请、建议委外工单、例外信息提示。计划员最关心的应该是例外信息，因为那是需要人工介入判断的地方。

例外信息的常见类型包括：需求日期早于当前日期（逾期需求）、可用库存为负、计划开工日早于当前日期、安全库存被突破但无需求覆盖等。处理顺序我建议固定下来：先处理逾期需求，再处理负库存警示，最后调整开工日期不合理的工单。逾期需求通常是销售端插单或交期承诺过短导致，需要反馈给销售重新确认交付时间，而不是直接压缩生产提前期。

处理例外信息的原则是「改参数优先于改结果」。比如批量规则导致下达量偏大，应该调整批量字段后重新运算；如果手工修改建议计划量，下次运算会被覆盖，治标不治本。F19支持保存运行方案，建议按「每周方案」「月度MTS补库方案」各存一套，避免每次运算参数不一致导致结果无法对比。

5. 高频计划异常排查：计划推不下去时先查这五件事

计划模块跑久了，总会遇到运算结果和实际预期不符的情况。很多计划员遇到偏差习惯性认为是系统有问题，实际上绝大多数异常是基础资料或业务流程上的缺口。这一章列五个我在项目里遇到次数最多的问题，每条都按现象、原因、解决来梳理。

5.1 物料短缺但库存显示有量？先查可用量而不是库存数量

现象是MRP运算结果提示某款封边带不满足需求，但库存查询界面明明显示有货。原因几乎都是这个物料的库存已被其他工单预分配，或者被冻结在某个仓库未参与计划运算。分配逻辑在运算参数里已说明，这里的关键在于计划员要习惯看可用量而不是库存总量。

解决方法是确认库存状态码。在计划运算参数里检查参与运算的仓库范围是否包含了原料仓库和线边仓，再看物料档案中是否设置了「不可用于计划」的库存状态。实际操作中还有一个常见原因：不良品库存和可用库存放在同一仓库但状态码不同，计划运算默认排除不良品库存，这属于正常逻辑而非异常。

5.2 BOM未审核或未生效导致的计划漏算

现象是新产品下单后，MRP运算结果里完全没有该产品的物料需求。原因是BOM处于未审核状态，或生效日期还没到。很多研发或工艺人员录入BOM后没有立即提交审核，等计划员跑运算时才暴露。

解决方法是建立BOM审核完成再通知计划组的流程。具体操作上，计划员可以在F19的基础资料里设置「未审核BOM参与计划」的选项，但不建议长期开启，它会放大BOM错误的成本。更稳妥的做法是每周核对一次新产品BOM的审核状态，让工艺部门在周例会前完成该周所有BOM审核。

5.3 提前期参数不当导致的计划变动频繁

现象是计划工单频繁提前或延后，供应商抱怨采购订单变更太多。原因是物料主数据里的提前期明显小于实际周期，系统按偏短提前期推算需求日期，导致晚于实际需求时间下单，采购无法按时交付。

解决方法是重新测量真实周期。采购提前期可以取最近三个月的平均到货周期加一天缓冲，生产提前期取最近三个月的实际生产周期平均值而不是标准工时总和。我遇到过某个家具厂的油漆工序提前期填了三天，实际外协周期是七天，调整参数后计划变动率立刻下降。

5.4 工作日历未维护导致交期测算偏差

现象是销售承诺的交期系统测算为不可能完成，或者反过来系统的建议交期明显晚于销售承诺。原因是工作日历里的可用工作日和实际排班不一致。家居厂常见的季节性加班在日历里没有反映，周六上班没标出来，系统自然按双休来排。

解决方法是每月二十五号前完成下月的日历维护，包括周末上班日、节假日调班、设备检修停工期。如果有多个车间且排班不同，要按车间维护独立日历，并在计划方案里指定各物料使用的日历编号。这条问题排查时最容易忽略，因为界面默认展示的日历总是看起来正常。

5.5 例外信息堆积：区分提示类与阻塞类

现象是MRP运算完成后例外信息有几百条，计划员看不过来干脆全部忽略。原因是例外信息分级设置不合理，F19默认把所有例外都当作提示级别，没有区分严重程度。

解决方法是在运算方案参数里做例外分级配置。逾期需求设为阻塞级，负库存设为阻塞级，提前期调整建议设为提示级。计划员每天只需要处理阻塞级的几十条，提示级的可以批量查看不必全处理。等级划分可以参考下面的配置逻辑：

6. 把计划从「能跑」做到「跑准」：三个可落地的进阶习惯

计划模块用起来只是第一步，让计划真正指导生产和采购还需要持续调优。最后分享三个我在项目上验证过有效的进阶习惯。

第一个习惯是每周核算计划达成率。用完工入库数量对比计划下达数量，如果一周达成率持续低于百分之八十，不要急着催生产，先检查排产是否留了合理缓冲。达成率的SQL统计口径建议统一为：按计划完工日期所在周统计实际入库数量。用下面这条SQL可以快速算出周达成率：

-- 按周一作为计划周期的生产工单达成率统计 SELECT DATE_FORMAT(DATE_SUB(wo.plan_finish_date, INTERVAL WEEKDAY(wo.plan_finish_date) DAY), '%Y-%m-%d') AS 计划周, COUNT(DISTINCT wo.wo_id) AS 计划工单数, COUNT(DISTINCT CASE WHEN wo.status = '完工' THEN wo.wo_id END) AS 完工工单数, ROUND(COUNT(DISTINCT CASE WHEN wo.status = '完工' THEN wo.wo_id END)/COUNT(DISTINCT wo.wo_id)*100, 1) AS 达成率 FROM wo_order wo WHERE wo.create_time >= :统计起期 AND wo.create_time < :统计止期 GROUP BY 计划周 ORDER BY 计划周;

这段SQL的统计口径是：把工单的计划完工日期换算到当周周一，再按周统计工单总数和完工数。注意wo_order表需要过滤删除标记和已取消的工单，否则统计会偏低。生产工单的完工状态维护要及时，车间报工如果滞后一天，统计结果就会偏差一天，所以达成率统计最好和车间日报一起做。

第二个习惯是建立计划快照机制。F19的系统版本和每日运算批次都留存在日志里，建议每周保存一次计划方案快照。方法很简单：运算完成后将建议计划量导出存档，或者直接在计划方案界面保留本周运算记录，不做删除归档。这样出现争议时可以回溯到某个时间点的计划版本，部门之间扯皮时能少很多麻烦。

第三个习惯是月度复盘计划参数。每个月底花半小时复盘三个参数：提前期的偏差率、安全库存被消耗的次数、批量规则的合理性。如果某种物料连续三个月未触发采购申请补货，说明安全库存偏高了；如果某种物料每月都触发多次插单采购，说明提前期设置过短或安全库存偏低。复盘结论需要和采购、生产负责人同步，形成调整记录，避免同一个人反复调整同一参数。

这三个习惯坚持三个月以上，计划模块的运算结果会和生产实际情况越来越接近。这也是我在多个项目里反复验证的路径——ERP计划管理的收益从来不在上线当天，而在持续调优的周期里。

做计划管理的这些年，我最大的体会是别指望一套参数模板走天下，每家工厂的产能节奏、供应商水平、订单结构都不一样，参数最终要靠自己的复盘数据来修正。系统只是把逻辑固化下来，真正让计划变准的，是不断对照执行结果调参数的那个过程。希望帮到你。

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