化妆品制造业 · Odoo ERP 实施方案
面向化妆品研发、生产、质量、合规与供应链一体化管理。本文是实施设计文档目标、技术架构、业务设计、分阶段上线路线、部署选型与运维风险。末附少量关键代码块(置于 <pre><code> 中),作为方案落地的佐证。
一、项目背景与诊断
化妆品制造业与通用离散制造最大的差异,在于它是一门口强监管、强追溯、配方即资产的生意。结合《化妆品监督管理条例》《化妆品生产经营监督管理办法》、GMPC 与 ISO 22716 体系,以及 NMPA 备案/注册要求,企业通常会遇到以下六类问题:
配方资产化难
配方多头管理、版本混乱、保密分级缺失,无法反算成本与成分清单(INCI)。
批次效期靠 Excel
原料/半成品/成品的批号与有效期分散在表格,临期靠人盯,极易漏警。
飞检追溯慢
监管飞检要求从成品批向上追到原料、向下追到发运,传统方式响应以小时计。
限用物质人工核
限用/禁用物质浓度靠人工比对,标签成分与备案一致性难以保证。
留样管理缺位
成品检验留样与稳定性考察无系统登记,到期报废全凭记忆。
成本归集粗
配方成本与单批实际耗用脱节,毛利与批次成本分析做不细。
stock / mrp / purchase / sale / account 等成熟模块,stock.lot 天然支持批次与效期,mrp.bom 支持多级配方。在其上做"化妆品语义"扩展,即可低成本覆盖 80% 诉求。二、建设目标
- 一体化闭环:研发 → BOM → 采购 → 仓储 → 生产 → 质检 → 合规 → 销售 → 财务,同一平台跑通。
- 可追溯:每一支/每一盒产品可定位到生产批、原料批、操作工、检验结果,飞检分钟级出单。
- 合规内置:备案编号、限用物质浓度校验、MSDS 关联作为业务必填项,而非事后补录。
- 成本可控:标准配方成本 + 实际生产归集,支撑毛利与批次成本分析。
- 上线平滑:4 阶段滚动上线,先标准模块后定制开发,降低业务中断风险。
版本取向:以 Odoo 17 CE 为核心承载(代码风格兼容 16/18)。若需要生产排程甘特、质量 App、Studio、国内电子发票等高级能力,需评估企业版(EE)许可成本,EE 作为可选增强而非前提。
三、总体技术架构
以标准模块为底座,上叠 7 个自研扩展模块承载化妆品行业语义。依赖关系自上而下,保证安装顺序与数据流向一致:
| 层级 | 模块 | 职责 | 关键技术点 |
|---|---|---|---|
| 底座 | product / stock / mrp / purchase / sale / account | 标准进销存、生产、财务 | Odoo 原生,零开发 |
| 扩展① | cosmetics_base | 产品品类、效期、存储条件、净含量、备案号、MSDS | 继承 product.template |
| 扩展② | cosmetics_formula | 配方编号/版本/保密/配方成本 | 继承 mrp.bom |
| 扩展③ | cosmetics_mrp | 生产批号、班次、操作工、批记录 | 继承 mrp.production / stock.lot |
| 扩展④ | cosmetics_quality | 来料/过程/成品/稳定性检验、留样 | 新模型 cosmetics.quality.check |
| 扩展⑤ | cosmetics_compliance | 成分库(限用/禁用)、备案/注册 | 新模型 ingredient / filing |
| 扩展⑥ | cosmetics_traceability | 成品批双向追溯 QWeb 报表 | 继承 stock.lot + QWeb |
| 扩展⑦ | cosmetics_alerts | 效期/留样到期自动预警 | 新模型 cosmetics.alert + ir.cron |
stock.lot 的上下游库存移动即可实现分钟级双向追溯,无需另建复杂模型。每个自研模块都是标准 Odoo 模块目录,__manifest__.py 用 depends 声明依赖、用 data 声明要加载的视图/权限文件。下面给出 cosmetics_base 的清单示例:
{
'name': 'Cosmetics Base',
'version': '17.0.1.0.0',
'category': 'Manufacturing',
'summary': '化妆品行业基础扩展(产品/批次/效期)',
'depends': ['product', 'stock', 'mrp'],
'data': [
'security/ir.model.access.csv',
'views/product_template_views.xml',
],
'installable': True,
'license': 'LGPL-3',
}
四、关键业务设计
4.1 配方与 BOM 管理
用 Odoo 的 mrp.bom 直接承载"配方"语义,避免引入平行于 BOM 的配方表导致数据双轨。扩展字段包括:配方编号、版本号、保密标记、配方说明、配方成本(按子件标准价 × 用量实时反算)。同一产品通过"配方编号 + 版本"组合唯一约束,支持配方升版与历史留痕。保密配方通过记录规则(ir.rule)对非研发角色隐藏明细。
4.2 批次与效期
全链路启用 stock.lot:原料、包材、半成品、成品均入批。在 stock.lot 上扩展生产日期、有效期至、品类、是否特殊化妆品等字段;有效期由"生产日期 + 产品保质期(月)"自动推算,减少人工录入误差。
4.3 双向追溯(监管飞检核心)
在 stock.lot 上实现 get_upstream_lots()(上溯原料批)与 get_downstream_lots()(下溯发运批)两个方法,基于已完成的 stock.move 滚动归集。绑定一个 QWeb PDF 报表到 stock.lot,飞检时一键打印"向上到原料、向下到客户"的全链路。核心方法如下:
class StockLot(models.Model):
_inherit = 'stock.lot'
def get_upstream_lots(self):
"""上溯到所有原料/半成品批:原料 -> 生产批 -> 成品批"""
lots = self
moves = self.env['stock.move.line'].search([
('lot_id', 'in', lots.ids), ('state', '=', 'done')])
while moves:
prev = moves.mapped('move_id.lot_ids') - lots
lots |= prev
moves = self.env['stock.move.line'].search([
('lot_id', 'in', prev.ids), ('state', '=', 'done')])
return lots - self
def get_downstream_lots(self):
"""下溯到发运/客户批:成品批 -> 发运批"""
lots = self
moves = self.env['stock.move.line'].search([
('move_id.lot_ids', 'in', lots.ids), ('state', '=', 'done')])
while moves:
nxt = moves.mapped('lot_id') - lots
lots |= nxt
moves = self.env['stock.move.line'].search([
('move_id.lot_ids', 'in', nxt.ids), ('state', '=', 'done')])
return lots - self
4.4 质量管理
新建 cosmetics.quality.check 模型,覆盖四类检验:来料、过程、成品、稳定性。记录 pH、粘度、微生物等理化指标与合格判定(statusbar:待定/合格/不合格)。成品检验自动触发留样登记,留样到期日按检验日期 + 365 天计算。_inherit mail.thread 使其自带消息与活动。
4.5 合规与备案
建立成分库(cosmetics.ingredient),标注限用/禁用及最大浓度,并用 @api.constrains 防止同一成分同时被标为限用与禁用。建立备案/注册档案(cosmetics.filing),关联产品模板与 NMPA 编号、类型(普通备案/特殊注册)、有效期。配方或成品在业务流中强制校验备案状态与限用物质浓度,把合规要求前置到操作环节。
五、分阶段实施路线
采用 4 阶段滚动上线,每阶段闭环验收后再进入下一阶段,最大限度降低对生产业务的冲击。
1阶段一 · 底座部署与基础数据(第 1–4 周)
- 完成服务器/Docker 部署 Odoo 17 + PostgreSQL 15。
- 安装标准模块:Contacts、Sales、Purchase、Inventory、MRP、Accounting、Invoicing。
- 梳理产品分类、计量单位、仓库库位、合作伙伴主数据。
- 导入物料主数据,安装
cosmetics_base补全行业字段。
2阶段二 · 生产与配方(第 5–9 周)
- 安装
cosmetics_formula,将研发配方转为带版本/保密的mrp.bom。 - 安装
cosmetics_mrp,配置生产批号规则、班次、操作工、批记录模板。 - 跑通主流程:销售订单 → 生产单 → 原料按批领用 → 成品入库(自动生成批号与效期)。
3阶段三 · 质量与合规(第 10–13 周)
- 安装
cosmetics_quality,建立来料/过程/成品检验与留样登记。 - 安装
cosmetics_compliance,录入限用/禁用成分库,维护备案/注册信息。 - 配置临期预警、不合格品处置、稳定性考察计划。
4阶段四 · 追溯、预警与优化(第 14–16 周)
- 上线双向追溯报表与监管飞检打印视图。
- 安装
cosmetics_alerts,启用每日效期/留样到期ir.cron预警。 - 权限角色细化(研发/生产/质检/仓管/合规/财务),编写 SOP 并培训。
角色权限建议:系统管理员、研发工程师、生产主管、质检员、仓管员、合规专员、财务。通过 ir.model.access.csv + 记录规则(ir.rule)实现数据隔离。
六、部署与版本选型
6.1 版本与形态
- 核心版本:Odoo 17 CE(兼容 16/18 代码风格)。EE 仅作为生产排程、质量 App、Studio 等增强的可选项。
- 承载形态:生产推荐 Docker Compose + PostgreSQL 15 + Nginx 反向代理;若上云可用对象存储接管 filestore。
6.2 资源与进程模型
进程数建议公式:workers = CPU核数 × 2 + 1;内存软上限约 2 GB/worker,硬上限约 2.6 GB/worker。启用 worker 模式后,Nginx 前置务必配置 proxy_mode = True 并正确转发 X-Forwarded-Proto。
6.3 附件存储
默认 filestore 位于 data_dir/filestore,备份与迁移必须连同数据库一起处理。生产建议挂对象存储或独立卷。
services:
db:
image: postgres:15
environment:
- POSTGRES_DB=odoo
- POSTGRES_USER=odoo
- POSTGRES_PASSWORD=odoo_pass
volumes:
- db_data:/var/lib/postgresql/data
restart: unless-stopped
odoo:
image: odoo:17.0
depends_on:
- db
ports:
- "8069:8069"
environment:
- HOST=db
- PORT=5432
- USER=odoo
- PASSWORD=odoo_pass
volumes:
- odoo_data:/var/lib/odoo
- ./addons:/mnt/extra-addons
restart: unless-stopped
volumes:
db_data:
odoo_data:
[options]
admin_passwd = admin_strong_password
db_host = db
db_port = 5432
db_user = odoo
db_password = odoo_pass
addons_path = /mnt/extra-addons
data_dir = /var/lib/odoo
workers = 5
limit_memory_soft = 2013265920
limit_memory_hard = 2684354560
proxy_mode = True
七、运维、备份与升级
- 模块安装/更新:模块放入 addons 目录 → 开启开发者模式 → Apps → 更新应用列表 → 安装或升级。
- 定期备份:每日执行数据库
pg_dump+ 拷贝 filestore,用 crontab 调度。 - 版本升级:先全量备份 → 拉取新镜像/源码 →
-u all或--upgrade-path。 - 日志排查:
docker compose logs -f odoo。
dropdb、删除 filestore、模块升级前,必须先完成备份并确认可回滚。八、风险与坑点提示
| 事项 | 建议与取舍 |
|---|---|
| Python / PostgreSQL 版本 | Odoo 17 支持 Python 3.10/3.11 + PostgreSQL 14/15/16。 |
| wkhtmltopdf | QWeb 打印 PDF 需 0.12.6,版本不匹配报表会报错。 |
| lessc / sass | 源码部署样式编译依赖 node-less;官方 Docker 镜像已内置。 |
| 视图 XPath 差异 | 不同版本视图 page 名称可能变化,安装报 XPath 找不到时按实际 view 调整。 |
| workers 与代理 | worker 模式 Nginx 必须开 proxy_mode = True。 |
| CE vs EE 边界 | 生产排程、质量 App、Studio、国内电子发票等属 EE。 |
化妆品制造业 · Odoo ERP 实施方案
面向化妆品研发、生产、质量、合规与供应链一体化管理。本文是实施设计文档目标、技术架构、业务设计、分阶段上线路线、部署选型与运维风险。末附少量关键代码块(置于 <pre><code> 中),作为方案落地的佐证。
一、项目背景与诊断
化妆品制造业与通用离散制造最大的差异,在于它是一门口强监管、强追溯、配方即资产的生意。结合《化妆品监督管理条例》《化妆品生产经营监督管理办法》、GMPC 与 ISO 22716 体系,以及 NMPA 备案/注册要求,企业通常会遇到以下六类问题:
配方资产化难
配方多头管理、版本混乱、保密分级缺失,无法反算成本与成分清单(INCI)。
批次效期靠 Excel
原料/半成品/成品的批号与有效期分散在表格,临期靠人盯,极易漏警。
飞检追溯慢
监管飞检要求从成品批向上追到原料、向下追到发运,传统方式响应以小时计。
限用物质人工核
限用/禁用物质浓度靠人工比对,标签成分与备案一致性难以保证。
留样管理缺位
成品检验留样与稳定性考察无系统登记,到期报废全凭记忆。
成本归集粗
配方成本与单批实际耗用脱节,毛利与批次成本分析做不细。
stock / mrp / purchase / sale / account 等成熟模块,stock.lot 天然支持批次与效期,mrp.bom 支持多级配方。在其上做"化妆品语义"扩展,即可低成本覆盖 80% 诉求。二、建设目标
- 一体化闭环:研发 → BOM → 采购 → 仓储 → 生产 → 质检 → 合规 → 销售 → 财务,同一平台跑通。
- 可追溯:每一支/每一盒产品可定位到生产批、原料批、操作工、检验结果,飞检分钟级出单。
- 合规内置:备案编号、限用物质浓度校验、MSDS 关联作为业务必填项,而非事后补录。
- 成本可控:标准配方成本 + 实际生产归集,支撑毛利与批次成本分析。
- 上线平滑:4 阶段滚动上线,先标准模块后定制开发,降低业务中断风险。
版本取向:以 Odoo 17 CE 为核心承载(代码风格兼容 16/18)。若需要生产排程甘特、质量 App、Studio、国内电子发票等高级能力,需评估企业版(EE)许可成本,EE 作为可选增强而非前提。
三、总体技术架构
以标准模块为底座,上叠 7 个自研扩展模块承载化妆品行业语义。依赖关系自上而下,保证安装顺序与数据流向一致:
| 层级 | 模块 | 职责 | 关键技术点 |
|---|---|---|---|
| 底座 | product / stock / mrp / purchase / sale / account | 标准进销存、生产、财务 | Odoo 原生,零开发 |
| 扩展① | cosmetics_base | 产品品类、效期、存储条件、净含量、备案号、MSDS | 继承 product.template |
| 扩展② | cosmetics_formula | 配方编号/版本/保密/配方成本 | 继承 mrp.bom |
| 扩展③ | cosmetics_mrp | 生产批号、班次、操作工、批记录 | 继承 mrp.production / stock.lot |
| 扩展④ | cosmetics_quality | 来料/过程/成品/稳定性检验、留样 | 新模型 cosmetics.quality.check |
| 扩展⑤ | cosmetics_compliance | 成分库(限用/禁用)、备案/注册 | 新模型 ingredient / filing |
| 扩展⑥ | cosmetics_traceability | 成品批双向追溯 QWeb 报表 | 继承 stock.lot + QWeb |
| 扩展⑦ | cosmetics_alerts | 效期/留样到期自动预警 | 新模型 cosmetics.alert + ir.cron |
stock.lot 的上下游库存移动即可实现分钟级双向追溯,无需另建复杂模型。每个自研模块都是标准 Odoo 模块目录,__manifest__.py 用 depends 声明依赖、用 data 声明要加载的视图/权限文件。下面给出 cosmetics_base 的清单示例:
{
'name': 'Cosmetics Base',
'version': '17.0.1.0.0',
'category': 'Manufacturing',
'summary': '化妆品行业基础扩展(产品/批次/效期)',
'depends': ['product', 'stock', 'mrp'],
'data': [
'security/ir.model.access.csv',
'views/product_template_views.xml',
],
'installable': True,
'license': 'LGPL-3',
}
四、关键业务设计
4.1 配方与 BOM 管理
用 Odoo 的 mrp.bom 直接承载"配方"语义,避免引入平行于 BOM 的配方表导致数据双轨。扩展字段包括:配方编号、版本号、保密标记、配方说明、配方成本(按子件标准价 × 用量实时反算)。同一产品通过"配方编号 + 版本"组合唯一约束,支持配方升版与历史留痕。保密配方通过记录规则(ir.rule)对非研发角色隐藏明细。
4.2 批次与效期
全链路启用 stock.lot:原料、包材、半成品、成品均入批。在 stock.lot 上扩展生产日期、有效期至、品类、是否特殊化妆品等字段;有效期由"生产日期 + 产品保质期(月)"自动推算,减少人工录入误差。
4.3 双向追溯(监管飞检核心)
在 stock.lot 上实现 get_upstream_lots()(上溯原料批)与 get_downstream_lots()(下溯发运批)两个方法,基于已完成的 stock.move 滚动归集。绑定一个 QWeb PDF 报表到 stock.lot,飞检时一键打印"向上到原料、向下到客户"的全链路。核心方法如下:
class StockLot(models.Model):
_inherit = 'stock.lot'
def get_upstream_lots(self):
"""上溯到所有原料/半成品批:原料 -> 生产批 -> 成品批"""
lots = self
moves = self.env['stock.move.line'].search([
('lot_id', 'in', lots.ids), ('state', '=', 'done')])
while moves:
prev = moves.mapped('move_id.lot_ids') - lots
lots |= prev
moves = self.env['stock.move.line'].search([
('lot_id', 'in', prev.ids), ('state', '=', 'done')])
return lots - self
def get_downstream_lots(self):
"""下溯到发运/客户批:成品批 -> 发运批"""
lots = self
moves = self.env['stock.move.line'].search([
('move_id.lot_ids', 'in', lots.ids), ('state', '=', 'done')])
while moves:
nxt = moves.mapped('lot_id') - lots
lots |= nxt
moves = self.env['stock.move.line'].search([
('move_id.lot_ids', 'in', nxt.ids), ('state', '=', 'done')])
return lots - self
4.4 质量管理
新建 cosmetics.quality.check 模型,覆盖四类检验:来料、过程、成品、稳定性。记录 pH、粘度、微生物等理化指标与合格判定(statusbar:待定/合格/不合格)。成品检验自动触发留样登记,留样到期日按检验日期 + 365 天计算。_inherit mail.thread 使其自带消息与活动。
4.5 合规与备案
建立成分库(cosmetics.ingredient),标注限用/禁用及最大浓度,并用 @api.constrains 防止同一成分同时被标为限用与禁用。建立备案/注册档案(cosmetics.filing),关联产品模板与 NMPA 编号、类型(普通备案/特殊注册)、有效期。配方或成品在业务流中强制校验备案状态与限用物质浓度,把合规要求前置到操作环节。
五、分阶段实施路线
采用 4 阶段滚动上线,每阶段闭环验收后再进入下一阶段,最大限度降低对生产业务的冲击。
1阶段一 · 底座部署与基础数据(第 1–4 周)
- 完成服务器/Docker 部署 Odoo 17 + PostgreSQL 15。
- 安装标准模块:Contacts、Sales、Purchase、Inventory、MRP、Accounting、Invoicing。
- 梳理产品分类、计量单位、仓库库位、合作伙伴主数据。
- 导入物料主数据,安装
cosmetics_base补全行业字段。
2阶段二 · 生产与配方(第 5–9 周)
- 安装
cosmetics_formula,将研发配方转为带版本/保密的mrp.bom。 - 安装
cosmetics_mrp,配置生产批号规则、班次、操作工、批记录模板。 - 跑通主流程:销售订单 → 生产单 → 原料按批领用 → 成品入库(自动生成批号与效期)。
3阶段三 · 质量与合规(第 10–13 周)
- 安装
cosmetics_quality,建立来料/过程/成品检验与留样登记。 - 安装
cosmetics_compliance,录入限用/禁用成分库,维护备案/注册信息。 - 配置临期预警、不合格品处置、稳定性考察计划。
4阶段四 · 追溯、预警与优化(第 14–16 周)
- 上线双向追溯报表与监管飞检打印视图。
- 安装
cosmetics_alerts,启用每日效期/留样到期ir.cron预警。 - 权限角色细化(研发/生产/质检/仓管/合规/财务),编写 SOP 并培训。
角色权限建议:系统管理员、研发工程师、生产主管、质检员、仓管员、合规专员、财务。通过 ir.model.access.csv + 记录规则(ir.rule)实现数据隔离。
六、部署与版本选型
6.1 版本与形态
- 核心版本:Odoo 17 CE(兼容 16/18 代码风格)。EE 仅作为生产排程、质量 App、Studio 等增强的可选项。
- 承载形态:生产推荐 Docker Compose + PostgreSQL 15 + Nginx 反向代理;若上云可用对象存储接管 filestore。
6.2 资源与进程模型
进程数建议公式:workers = CPU核数 × 2 + 1;内存软上限约 2 GB/worker,硬上限约 2.6 GB/worker。启用 worker 模式后,Nginx 前置务必配置 proxy_mode = True 并正确转发 X-Forwarded-Proto。
6.3 附件存储
默认 filestore 位于 data_dir/filestore,备份与迁移必须连同数据库一起处理。生产建议挂对象存储或独立卷。
services:
db:
image: postgres:15
environment:
- POSTGRES_DB=odoo
- POSTGRES_USER=odoo
- POSTGRES_PASSWORD=odoo_pass
volumes:
- db_data:/var/lib/postgresql/data
restart: unless-stopped
odoo:
image: odoo:17.0
depends_on:
- db
ports:
- "8069:8069"
environment:
- HOST=db
- PORT=5432
- USER=odoo
- PASSWORD=odoo_pass
volumes:
- odoo_data:/var/lib/odoo
- ./addons:/mnt/extra-addons
restart: unless-stopped
volumes:
db_data:
odoo_data:
[options]
admin_passwd = admin_strong_password
db_host = db
db_port = 5432
db_user = odoo
db_password = odoo_pass
addons_path = /mnt/extra-addons
data_dir = /var/lib/odoo
workers = 5
limit_memory_soft = 2013265920
limit_memory_hard = 2684354560
proxy_mode = True
七、运维、备份与升级
- 模块安装/更新:模块放入 addons 目录 → 开启开发者模式 → Apps → 更新应用列表 → 安装或升级。
- 定期备份:每日执行数据库
pg_dump+ 拷贝 filestore,用 crontab 调度。 - 版本升级:先全量备份 → 拉取新镜像/源码 →
-u all或--upgrade-path。 - 日志排查:
docker compose logs -f odoo。
dropdb、删除 filestore、模块升级前,必须先完成备份并确认可回滚。八、风险与坑点提示
| 事项 | 建议与取舍 |
|---|---|
| Python / PostgreSQL 版本 | Odoo 17 支持 Python 3.10/3.11 + PostgreSQL 14/15/16。 |
| wkhtmltopdf | QWeb 打印 PDF 需 0.12.6,版本不匹配报表会报错。 |
| lessc / sass | 源码部署样式编译依赖 node-less;官方 Docker 镜像已内置。 |
| 视图 XPath 差异 | 不同版本视图 page 名称可能变化,安装报 XPath 找不到时按实际 view 调整。 |
| workers 与代理 | worker 模式 Nginx 必须开 proxy_mode = True。 |
| CE vs EE 边界 | 生产排程、质量 App、Studio、国内电子发票等属 EE。 |
立即咨询,按需定制