企业官网建设流程全解析

简介：针对流程型生产制造行业的信息化痛点，这份技术方案文档基于Odoo免费开源ERP平台，系统梳理了从客户档案、销售订单、生产设置、班次定义、主数据管理到主生产计划与排产确认的完整落地路径。方案突出开源灵活、源码100%交付、贴合一线操作工移动端应用、支持工业互联设备数据交互等特点，非常适合中小型铸造、化工、食品等流程型生产企业用于选型评估或实施参考。文档对配方管理、锅炉溶解等核心场景有具体说明，并给出了造型工序生产全过程执行示例，便于理解排产与追溯逻辑。包体为单个docx文档，容量仅758KB，内容精炼但覆盖了核心功能模块与典型业务场景。目前已有389人学习下载，对于正在考虑低成本上云、希望自主可控ERP系统的企业信息化负责人具有较高参考价值。

1. 为什么流程型生产企业需要一份Odoo技术方案，而不是散装Excel

铸造、化工、食品这类流程型生产企业，车间里最值钱的往往不是某台设备，而是藏在老师傅脑子里的配方比例、锅炉溶解参数和排产经验。原料批次一变要微调配比，锅炉产能不够要压缩产量，某个班组临时缺人还要重排任务——这些场景下，通用ERP的固定流程根本接不住。Odoo免费开源ERP最大的优势就是模块开放、数据模型可改，能按流程型生产的实际业务重排单据链路。这份技术方案把客户档案、销售订单在线确认、设备OEE、班组班次、配方主数据、主生产计划、排产回写这一整条链路完整梳理了一遍，适合正在选型的中小型制造企业负责人、生产主管和ERP实施顾问对照着落地。它不是讲Odoo怎么安装的说明书，而是讲流程型制造信息化怎么切入的实战参考资料。

2. 制造模式的差异决定ERP选型：为什么流程型生产不能照搬离散型方案

2.1 三种制造模式：流程型、离散型与柔性型的业务特征对比

很多企业选型失败，第一步就栽在对自身制造模式的判断上。方案文档里把制造业分成三类，这个分类直接决定了BOM结构、生产单据和排产逻辑的设计方式。我见过不少机械加工厂老板拿着离散型的生产管理思路去套食品车间的配方管理，结果车间根本用不起来。三类模式的差异不是概念问题，是系统建模的根本分叉。

流程型生产的特点是生产过程连续，BOM相对简单，更多是配方形式，管控重心在投入产出、批次追溯、设备利用率和班组成本。离散型生产正好反过来，BOM层级复杂，生产过程由多道工序、多个零件组合而成，管控重心在过程进度和在制品跟踪。柔性型生产介于两者之间，工艺有离散特征，但按产线化、细胞单元式组织，注重单件流和工位级追溯，典型代表是电子加工和装配行业。

流程型生产还有一个容易被忽略的特征：流程与流程之间有同步、前道作业、反复流转的需求，但工艺流程在系统初始化时往往相对固定，不会因为产品差异频繁调整。这意味着工艺路线可以提前固化，工序控制点、报废节点、班次绑定这类规则可以在系统里做成标准配置，不像离散型生产那样每条产品线都要单独建模。

2.2 Odoo为流程型生产提供了哪些技术支撑

Odoo被选作这类方案的基座，核心不是因为免费，而是因为它的模块化架构和数据模型适合按行业做二次封装。销售、库存、制造、质量、设备维护这些模块可以独立安装，也可以按业务流程串联起来。方案文档提到的客户档案、销售订单、生产设置、生产主数据、主生产计划，本质上就是Odoo原生模块加自定义字段、自定义模型的组合。

配方管理就是一个典型例子。Odoo原生的物料清单（BoM）模型偏向离散制造的多层级结构，流程型生产企业需要的配方版本、溶解参数、模具关联这些信息，原生模型并没有直接提供，但通过扩展product.template和mrp.bom模型就能把配方字段补全。这就是开源平台的价值——不用推翻标准模型，在原有数据表上做增量扩展就行。

另一个技术支撑点是开放接口。流程型生产企业往往有DCS、PLC这类工业设备数据要采集，方案里提到的IOT设备数据交互，在Odoo里一般通过外部API或者MQTT网关把设备产量、温度、能耗数据写回工单或设备卡片。系统源码100%交付，意味着这些对接代码完全由企业自己掌控，不需要依赖某个特定实施方的闭源中间件。

有一点要提醒：这套方案的排产逻辑不等于APS高级排产。它解决的是“销售订单自动转成生产计划、按设备产能修正、按班组班次下发任务”这个层级的排产需求，适合计划相对稳定的中小型流程型企业。如果车间有几十台设备、几千道工序、需要分钟级排产优化，这套方案的边界就够不到了，需要再叠加专业排产引擎。

3. 方案核心模块拆解：从客户档案到排产回写的完整链路

3.1 客户档案与销售订单：把定制需求和议价过程固定进单据源头

流程型生产企业最怕的不是订单多，而是订单信息在传递过程中走样。客户报了一个特殊配方要求，业务员记在微信里，跟单员转述给生产计划，到了车间就变成了“大概这样”。方案里把客户档案和销售订单作为整条链路的起点，就是为了把信息不对称的问题堵在源头。

客户档案模块在落地时，核心是统一客户主数据。客户基础档案信息用于定义客户资料，并关联后续的业务单据追踪。方案里提到的“按客户所在地区国家实现国际化业务单据自动转译套打”，对应到Odoo里就是res.partner模型上的国家字段和打印模板的多语言支持。多联系信息与销售、发票、收货关联，则在partner上维护多个联系人记录，每个联系人挂不同的业务单据。设置账期与业务员之后，销售数据的归属和回款周期就能自动带出。

销售订单的价值不只是记录交易，而是把客户的定制生产信息直接带进单据。方案文档里提到“根据成品档案维护的专属客户定制信息，在销售过程中明确呈现”，落地做法是在产品档案上增加custom_info字段，然后通过销售订单行上的说明字段自动带出。B2B在线客户订单手签确认，则是单独定制一个外部页面，客户登录后查看订单详情和定制参数，确认后回写状态，避免电话口头确认后期扯皮。

3.2 生产设置：设备OEE、工艺控制点和班组班次的建模方式

生产设置模块是整个方案里技术含量最高的一块，它把设备、工艺、班组三件事绑定到了一起。设备信息维护的目标是OEE管理和设备级成本核算；工艺流程定义则引入了“控制点”的概念——属性为排产节点的会影响生产任务计划数，属性为报废节点的实现生产过程中报废处理。这两个控制点属性，就是流程型生产把计划逻辑和报废逻辑揉进工艺路线的关键设计。

在Odoo里，工序和工艺路线对应的原生模型是mrp.routing.workcenter。要在方案中实现“排产节点”和“报废节点”的区分，常用做法是在这个模型的工序行上扩展一个control_point选择字段：

from odoo import models, fields class MrpRoutingWorkcenter(models.Model): _inherit = 'mrp.routing.workcenter' control_point = fields.Selection([ ('normal', '普通工序'), ('plan', '排产节点'), ('scrap', '报废节点'), ], string='控制点属性', default='normal', required=True) scrap_reason_ids = fields.Many2many( 'mrp.scrap.reason', string='报废原因', help='报废节点可选的报废原因，移动端一键选择，统计数据更干净')

这段代码的逻辑是给每一道工序增加“控制点属性”标签。后续生成生产计划任务时，系统只看control_point为plan的工序，以此为节点计算排产数量和计划日期；生产执行中出现报废时，操作工在手机端进入控制点为scrap的工序节点，选择报废原因完成报废作业。参数说明：plan节点会影响生产任务计划数，设置时要保证每个产品族的工艺路线上至少有一个plan节点，否则排产任务生成时会漏单；scrap节点最好把报废原因维护全，比如原料异常、设备异常、配方偏差，不然工人为了省事会直接选默认原因，后面追溯数据就没意义了。

班次和班组的建模，方案里也给了明确的设计方向。生产班次定义规则序列号，可追溯生产过程中的节点信息及班组、操作工信息；班组与工序工艺绑定，确保生产执行单据自动生成。实施时可以在mrp.workcenter上增加shift_ids和team_id字段，把班次日历和班组直接挂到工位上，这样任务单下发时自动带出班组和操作工，计件和工时成本也能随之归集到班组维度。

3.3 生产主数据：配方、模具、原料、辅料、图纸的集中管理

流程型生产企业的BOM虽然简单，但主数据范围反而比离散型更杂。方案里列出的主数据对象包括成品、模具、原料、辅料、配方、图纸，其中配方与工具会贯穿整个生产的核心过程，原料与辅料是产品制造的基础信息。这些主数据如果不能统一集中化管理，后面的排产、领料、成本核算全部会出问题。

配方的管理是这部分的重头戏。以锅炉溶解为例，溶解温度、保温时间、添加顺序、原料批次都可能影响成品质量，这些信息必须固化在配方档案里。Odoo原生的BoM模型可以管理配方行和替代料，但锅炉溶解所需的工艺参数，比如温度、压力、时长，需要在BoM上扩展自定义字段。常见做法是在mrp.bom上增加溶解温度、保温时长、搅拌速度等字段，并在BoM行上维护原料配比。

图纸管理则是另一块容易被忽略的主数据。生产过程中工人拿着纸质图纸去操作台上翻找，不仅效率低，版本还容易混淆。方案里提到图纸统一管理、支持拖拉拽批量上传，落地时一般通过Odoo的ir.attachment附件模型挂到产品档案上，按产品编码归档，移动端直接打开查看。这里有一个实施细节：图纸最好在附件上增加version版本字段，并设置审批状态，否则技术员改版后忘了更新，车间看到的还是旧图纸，生产出的产品自然就偏了。

3.4 主生产计划与排产确认：订单自动排计划、设备修正产量、报废回写

主生产计划模块解决的核心问题，是销售订单批量涌入时怎么有序地转成生产任务。方案的设计思路是：源销售订单信息自动代入排产计划，根据成品的排产计划时间自动安排计划完成日期，再根据锅炉等流程型生产设备调整产量数据。

这里的“自动代入”不是简单的复制粘贴。销售订单确认后，系统要把订单行转成生产计划草稿，并根据产品档案上的提前期和当前设备负荷计算建议开工日期。方案里特别提到“可根据锅炉等流程型生产设备调整产量数据”，这是因为锅炉、溶解炉这类设备存在最小批量限制，一炉可能只能熔多少吨，订单量不满一炉时不能简单按订单数量排产，要按炉批合并或拆批。

在Odoo里，这个逻辑通常是对mrp.production模型做扩展，增加源销售订单关联和待排产剩余量字段：

class MrpProduction(models.Model): _inherit = 'mrp.production' source_sale_line_id = fields.Many2one( 'sale.order.line', string='源销售订单行', help='销售订单自动生成生产计划时，保留来源订单行记录') remaining_qty = fields.Float( string='待排产剩余量', compute='_compute_remaining_qty', help='报废或变更后回写的剩余数量，用于继续安排生产') def _compute_remaining_qty(self): for production in self: done_qty = sum(production.move_line_ids.filtered( lambda ml: ml.state == 'done').mapped('quantity')) production.remaining_qty = production.product_qty - done_qty

代码逻辑说明：source_sale_line_id字段保留生产单与销售订单行的关联关系，这样任何一张生产单都能追溯到源头订单；remaining_qty是计算字段，用计划数量减去已经完成的数量，得到待排产剩余量。参数说明：当生产过程出现报废或特殊情况需要变更时，系统回写待排产数量，剩余量可以继续安排生产任务，而不是把原单直接作废重来。这个字段对流程型生产企业尤其重要，因为一炉产品往往跨越多个批次，部分报废是常态，没有剩余量回写机制，计划和车间就永远对不上账。

排产确认环节的落地步骤，方案也写得很清楚：按工艺流程定义生成班组班次的生产计划任务；批量筛选需要排产的订单；生产主管根据交期和货量做生产波次批量管理；确认开工日期后下发执行。造型（起始端）生产全过程执行时，创建造型子生产计划执行单，根据排产计划添加关联主生产任务单，形成主任务单—子执行单的层级结构，方便后续追踪造型环节的投入和产出。

4. 实施路径与避坑记录：五个落地节点和四条翻车教训

4.1 建议实施顺序：五个节点

系统上线最忌一上来就全模块铺开。流程型生产企业的主数据复杂、车间习惯固化，分阶段走比一步到位稳妥得多。我一般会把实施过程切成五个节点，每个节点有明确的交付物和验收标准。

第一个节点是基础环境搭建和模块清单确认。按销售、生产、库存、质量、设备维护的优先级把模块装好，配好公司结构、仓库结构、会计科目。第二个节点是主数据清洗，这是最耗时的一步。产品编码规则、原料批次管理、配方版本、模具档案，全部要在期初导入前定好规则，缺少编码规范后面每张单据都会乱。第三个节点是工艺路线和班组班次绑定，把所有产品的工艺流程在系统里固化，设置排产节点和报废节点，把班组、班次、操作工关联到对应工序。第四个节点是销售到生产的业务联调，跑通销售订单→生产计划→排产→生产工单→领料→完工→质检→入库的完整闭环。第五个节点是试运行，选一个产品族跑两周，每天核对计划数与完工数，再逐步扩大范围。

4.2 初始化参数怎么填：配方版本、工序节点、班次规则的推荐写法

初始化参数的填写质量直接决定系统能不能用起来。配方版本建议采用“成品编码+版本号”的编码规则，比如CL-001-V2，每次配方调整必须新增版本，不允许在原版本上直接改，否则追溯时根本说不清用的是哪版配方。工序控制点的设置，排产节点选在工艺路线的关键瓶颈工序上，不要每道工序都设成排产节点；报废节点则选在质量检验发现的工序位置，化工行业通常在反应完成后的检验工序，食品行业通常在包装前的金属检测工序。

班次规则的设置要贴合车间的实际倒班方式。Odoo里每个班次要定义开始时间、结束时间、工作时长和跨天规则，三班倒的企业还要设置班次轮换规则。建议把班次直接绑定到工位上，而不是绑定到产品上，这样排产任务创建时系统能自动根据工位日历带出可用的班组班次。班组绑定的操作工要一次维护到位，包括姓名、工号、工种，因为这些信息会跟着生产记录一起进入追溯链条。

4.3 高频踩坑记录：现象、原因与解决

配方版本混乱。现象是车间执行工单时领用的原料和工艺参数与当前配方不一致，产出的产品批次检测不合格。原因是配方初始化时没有启用版本管理，技术员直接在原配方上修改，保存后旧工单引用的也变成了新配方。解决方法是启用BoM版本字段，所有配方变更走版本递增，生产工单创建时锁定当时生效的BoM版本，不要允许工单中途切换配方版本，特殊情况必须走变更审批。

排产回写不生效。现象是生产过程中出现报废后，剩余量没有回到待排产池，计划员只能手动新建生产单。原因是报废节点没有配置为控制点，报废作业完成后没有触发剩余量回写逻辑。解决方法是检查所有产品工艺路线上的报废节点，确保control_point等于scrap，并在生产单模型上确认remaining_qty计算逻辑覆盖了报废数量扣减。我当时调这个逻辑花了整整一个下午，最后发现是报废原因里有几个记录没有关联到工序节点，生产单根本不知道这笔报废该算在哪个工序头上。

班组班次无法自动带出。现象是排产确认后生成的生产任务单里班组和班次字段全是空的，计划员只能手工补录。原因是班组虽然绑定了工艺路线，但工位上没有配置班次日历，生产任务创建时找不到可用的班次资源。解决方法是把班次日历挂到工位（workcenter）上，并设置好轮班规则，排产时系统按工位日历推荐可用班次。

销售订单定制信息漏传。现象是客户在下单时备注的定制要求，到了生产工单上完全看不到，车间按通用工艺生产，导致客户拒收。原因是定制字段只加在了销售订单页面上，没有通过传播字段传递到生产工单。解决方法是梳理一条字段传播链：销售订单行→生产计划→生产工单→工单说明，确保定制信息随单据流转。这个字段的传播规则要在上线前测一遍，不要只测试正向流程，还要测中途变更订单定制信息后，已生成的工单是否同步更新。

5. 上线后验证什么：用OEE、配方追溯和排产回写确认方案真落地

5.1 四个验证指标

系统上线不等于方案落地。真正能说明方案起作用的，是几个关键数据指标在试运行期间的走势。排产覆盖率看有多少销售订单能在系统里自动生成排产计划并确认开工日期，低于90%说明排产业务链路还有断点；准时开工率看工单是否按计划日期开工，这个数据能反映班次日历和班组分配是否合理；设备OEE能反映设备产能信息的准确性，如果OEE和实际产能对不上，说明设备档案里的产能参数是拍脑袋填的；报废率和返工率则直接关联追溯体系是否真实运转，如果车间根本没有通过系统报报废，那这个指标会异常地低，反而不正常。

5.2 一个低成本验证技巧：看板加定时脚本盯住排产回写

我不太建议一上线就上大屏报表，成本高，车间还不一定用。更实在的做法是用看板视图加一个定时脚本，把排产回写和完工数据每天自动汇总出来。先在生产单模型上建几个公式字段，按班组、按完工状态分组，用看板视图展示当日待排产、已开工、已完工、已报废的数量。然后写一个定时任务，每天早班开始前把前一天的数据抓出来推送：

from datetime import datetime, timedelta yesterday_start = datetime.now().replace( hour=0, minute=0, second=0, microsecond=0) - timedelta(days=1) yesterday_end = datetime.now().replace( hour=0, minute=0, second=0, microsecond=0) orders = env['mrp.production'].search([ ('date_finished', '>=', yesterday_start), ('date_finished', '<', yesterday_end), ]) for order in orders: if order.state == 'done': print(f"工单 {order.name} 完工 {order.product_qty}，班组 {order.team_id.name}") elif order.state == 'cancel': print(f"工单 {order.name} 取消，待排产剩余 {order.remaining_qty}")

这段脚本的逻辑是拉取昨天完工或取消的生产单，打印完工数量和取消工单的待排产剩余量。参数说明：date_finished是生产单的实际完工日期，用datetime区间过滤能确保只统计昨天；state为done判定完工，为cancel判定取消，重点盯cancel单的remaining_qty是否回写成功。把这段脚本挂到cron定时任务里，每天早上自动跑一遍，排产回写有没有失效，当天就能发现，不用等月底对账才暴露。

配方追溯的验证更直接：随机抽一个完工批次的原料领用记录，和配方BOM逐项比对，看领用数量是否一致、批次号是否完整。这条链路一旦出现断裂，说明车间执行时绕开了系统，要回头查是操作繁琐还是流程不合理，而不是逼着车间硬填。

我从那以后每次给流程型客户上线方案，都会强制自己在试运行期间走一遍这三个步骤：看排产覆盖率、抽查配方追溯、盯一天报废回写数据。这套动作能挡住大部分“系统上了但没人用”的翻车现场。希望帮到你。

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