企业官网建设流程全解析

简介：面向Odoo 16入门与实施人员的完整指南，以开源智造GoodERP为蓝本，从系统管理员权限、公司开户行设置、用户权限等基础配置讲起，逐步深入到仓库管理、采购流程、销售发货、销售收款、销售退货、特定场景处理、现金管理、组装生产、委外加工、MRP分析、外贸多币种等高频业务场景，并专章介绍数据库管理、开发者模式、导入导出、键盘快捷键、默认值设置、文档打印等使用技巧。资源为单个PDF文档，共9.01MB，目录近二十章，既能帮助实施顾问按图索骥，也能让企业IT人员在排错时快速定位；针对销售员只能看到自己客户、误删除出库单、折旧科目反了等真实痛点给出了具体处理建议。目前已有276人学习，可以作为从数据初始化到上线运维的随身手册，助力读者建立Odoo项目落地的完整认知框架，高效跨过实施中的常见门槛。

1. Odoo 16实施到底在做什么：一张销售订单背后的模块协作场景

A同事所在的某小型工贸公司半年前换了Odoo 16，实施顾问只调了三周，就把销售、采购、库存和会计全串到了一起。你也许看过演示界面，觉得Odoo就是个进销存加网页后台，但真实实施的任务远不止装个软件那么简单。它要解决的是：销售员在系统里点下「确认订单」，库存有没有货、该不该向供应商补货、月底财务怎么入账，这一连串动作能不能自动衔接。本文讲的就是这条链路背后，Odoo 16实施的入门路径——从技术底座选型、环境搭建、模块配置到权限和数据迁移，哪些参数决定成败，哪些坑几乎人人会踩。

2. 实施前的技术底座：Python版本、PostgreSQL与模块加载机制

2.1 Odoo 16的版本特性与运行环境选型

Odoo 16和过往版本最明显的区别是前端框架换成了OWL（Odoo Web Library），后端仍然是Python 3.8以上的标准Web应用。实施时很多配置界面变了，但底层的ORM（对象关系映射）逻辑没有根本性变化，所以网上老版本的教程里「模型」「视图」「权限」这些概念依然能复用。选运行环境时，我一般会先确认三件事：操作系统（生产用Ubuntu 22.04或Debian 11居多）、Python版本（3.10最稳）、数据库版本（PostgreSQL 12以上，生产习惯用14）。

不建议在Windows上部署生产环境，倒不是说跑不起来，而是后面的多进程worker配置、定时任务cron和备份脚本在Linux下更省心。开发环境可以用Docker先跑通，但实施调试时我更喜欢直接用apt装的裸环境，因为改配置文件、看日志、重启服务都更直观，少一层网络隔离，排查问题快很多。

2.2 模块机制：应用、依赖与加载顺序

Odoo把功能拆成一个个「模块」（addon）。一个模块就是一个包含__manifest__.py、Python模型文件、XML视图文件、CSV权限文件和静态资源的目录。实施的核心工作，就是决定启用哪些模块、调整哪些模块里的数据。很多刚接触的人把「安装应用」理解成点一下界面上的安装按钮，其实那只是最后一步。模块真正起作用要经过：加载__manifest__.py声明依赖、导入Python模型、执行XML数据文件（菜单、视图、字段定义）、应用权限记录。任何一个环节报错，整个模块都会显示安装失败。

依赖关系是最容易忽略的。比如你要用库存模块，__manifest__.py里depends必须写好'stock', 'sale_management'。Odoo启动时会按依赖顺序加载模块，如果A依赖B但B没装，系统不会自动帮你装好，只会直接报错。实施前把模块依赖图画清楚，比急着写代码更重要。

2.3 为什么是PostgreSQL而不是MySQL

Odoo官方只支持PostgreSQL，这一点经常被人忽略。原因是Odoo的ORM用到了一些PostgreSQL特有的能力：比如jsonb字段类型存储动态属性、store="True"的计算字段依赖数据库触发器、事务隔离级别和行级锁在并发写订单时更可靠。如果你用MySQL，会在安装模块时遇到column type "jsonb" does not exist之类的错误。

数据库参数里最影响实施体验的是连接数和字符集。安装时建议直接把字符集建为UTF8，排序规则用C.UTF-8或en_US.UTF-8，避免后面中文排序和检索出问题。连接数方面，默认max_connections=100对单机部署够用，但如果规划了多个Odoo worker进程，每个worker会占一个数据库连接池，小规模工贸公司50个并发用户以内不用太焦虑，超过再调也不迟。

3. 从零到跑通：Odoo 16安装、配置与第一个模块启用

3.1 安装前提：系统源、用户创建与数据库初始化

最常见的方式是直接用官方APT源安装，我通常按下面这套顺序操作。注意每一行命令都值得做完再继续，别图快一起复制。

# 以Ubuntu 22.04为例，先更新系统源 sudo apt update && sudo apt upgrade -y # 安装基础依赖：Python3、PostgreSQL、构建工具 sudo apt install -y python3 python3-dev python3-venv postgresql \ build-essential wget git nano # 创建Odoo系统用户，这里用odoo16作为用户名 sudo useradd -m -d /opt/odoo16 -s /bin/bash odoo16 # 创建PostgreSQL用户，密码与后续配置对应 sudo -u postgres createuser -d -R -S odoo16 sudo -u postgres psql -c "ALTER USER odoo16 WITH PASSWORD 'odoo16_pass';"

解析一下这几步：-d给用户建库权限，-R禁止创建角色，-S禁止超级用户权限，这是安全基线，生产环境不要放开。Odoo连接数据库时默认会用当前系统用户名去匹配PostgreSQL角色，所以我把系统用户和数据库用户都命名为odoo16，能少踩一层认证失败的坑。

3.2 配置文件 odoo.conf 的参数含义

官方安装包默认读/etc/odoo16/odoo.conf，我手动部署时会在/opt/odoo16下建配置。核心参数如下：

[options] addons_path = /opt/odoo16/addons,/opt/odoo16/odoo/addons db_host = 127.0.0.1 db_port = 5432 db_user = odoo16 db_password = odoo16_pass db_name = odoo16_prod list_db = False admin_passwd = 请改成强密码 logfile = /var/log/odoo16/odoo.log log_level = info workers = 3 limit_time_cpu = 60 limit_time_real = 120

list_db = False这个参数容易被新手忽略，默认True会在登录页显示所有数据库名，等于把你的库名暴露给外部探测，实施完建议关掉。admin_passwd是创建/备份/还原数据库用的管理密码，不是用户密码，很多人混淆，导致后续自动化脚本里db参数报错。workers表示多进程数，一般推荐 CPU核数减1，内存小于2GB的机器设成1或2就好，这不只是一个性能参数，也决定了同时处理文件上传和长时间报表的能力。

3.3 启动服务与创建第一个数据库

配置写好后，启动命令要区分前台调试和后台服务两种方式。我开发调试时直接前台跑：

sudo -u odoo16 /opt/odoo16/odoo/odoo-bin \ -c /etc/odoo16/odoo.conf \ --db-filter=odoo16_% \ --dev=all

--db-filter=odoo16_%是库名的正则过滤，加了这个参数后，登录页的库会被限定为以odoo16_开头，安全性和list_db=False是两层保护。--dev=all会让代码修改即时生效，XML视图错误直接显示在界面上，不用重启服务，这在调视图的时候是真省时间。

启动日志里看到HTTP service running on port 8069说明Web服务起来了，再重点看一眼有没有ERROR。首次访问http://服务器IP:8069/web/database/selector会让你创建数据库，填管理员密码（也就是配置文件里的admin_passwd），数据库名建议按odoo16_项目代号命名，方便后面多个项目共用一个实例时做备份和过滤。

3.4 启用第一个模块：从界面操作到模块目录结构

创建数据库后进入应用列表，搜索「销售」安装sale_management。这一步会连带安装联系人、产品、收款等基础模块。界面上点安装很快，但你要知道它往数据库里写了什么：ir_module_module表里标记了已安装状态，ir_model_fields里增加了几百个字段定义，菜单和权限记录也全量写进了ir_ui_menu和res_groups。所以如果你在界面上安装失败，去看日志比反复重装有用，最常见的原因是depends里的某个模块没装，或者XML里引用了不存在的视图ID。

如果你要开发的不是标准应用而是自定义功能，就得自己建模块目录。最小结构长这样：

custom_material/ ├── __init__.py ├── __manifest__.py ├── models/ │ ├── __init__.py │ └── material_management.py ├── security/ │ └── ir.model.access.csv ├── views/ │ ├── material_management_views.xml │ └── menu_views.xml └── data/ └── demo_data.xml

__manifest__.py里写'name': 'Custom Material','depends': ['base', 'stock'],'data': [...]按顺序列出要加载的XML和CSV文件。文件顺序不是随便排的，必须先定义动作和模型字段，再定义菜单和视图，否则会报External ID not found。

4. 把业务落进去：自定义模块、权限矩阵与数据迁移的完整路径

4.1 自定义模块的基础骨架：manifest.py 关键字段

实施过程中至少会碰到一两次「标准功能差一点，需要自己加字段或加表」的需求，所以自定义模块是最值得先打通的能力。下面这个manifest是实战里够用的最小模板：

{ 'name': 'Custom Material Management', 'version': '16.0.1.0.0', 'category': 'Manufacturing', 'summary': '物料档案扩展', 'depends': ['base', 'stock', 'sale_management'], 'data': [ 'security/ir.model.access.csv', 'views/material_management_views.xml', 'views/menu_views.xml', 'data/demo_data.xml', ], 'installable': True, 'application': True, 'license': 'LGPL-3', }

几个字段单独说。depends不是越长越好，每多一个依赖就意味升级和卸载时要连带处理更多数据。data里的文件顺序要遵守「模型字段 → 菜单 → 视图动作」的次序，先加载的表单里如果引用了还没加载的动作，会直接Element cannot be located。application表示它是否作为一个顶级应用出现在「应用」菜单里，业务扩展模块设成True，纯底层扩展设成False更合适。

4.2 模型定义：从基础字段到关联字段

在models/material_management.py里定义一个物料扩展模型，代码如下：

from odoo import models, fields, api class MaterialManagement(models.Model): _name = 'material.management' _description = '物料扩展信息' _rec_name = 'material_code' material_code = fields.Char(string='物料编码', required=True) material_name = fields.Char(string='物料名称', required=True) spec = fields.Char(string='规格型号') unit = fields.Many2one('uom.uom', string='计量单位') category = fields.Many2one('product.category', string='物料分类') cost_price = fields.Float(string='标准成本', digits=(10, 2)) stock_quantity = fields.Float(string='当前库存', compute='_compute_stock', store=True) @api.depends('related_product_id') def _compute_stock(self): for record in self: if record.related_product_id: record.stock_quantity = record.related_product_id.qty_available else: record.stock_quantity = 0 related_product_id = fields.Many2one('product.product', string='关联产品')

_rec_name很关键，它决定在别的地方引用这条记录时下拉框显示什么。不设置的话默认显示material.name，如果你没定义name字段，列表会显示成material.management加一堆ID，很难看。compute字段加了store=True后，Odoo会建数据库列来缓存计算结果，查询快，但要注意它只在依赖字段变化时重算，如果你直接改库存表的数据而不触发related_product_id变更，这个缓存不会自愈。

4.3 视图描述：表单、列表与搜索的XML写法

视图是实施里最容易反复调的部分。一个表单视图的基础写法如下：

<record id="material_management_view_form" model="ir.ui.view"> <field name="name">material.management.form</field> <field name="model">material.management</field> <field name="arch" type="xml"> <form string="物料"> <sheet> <group> <group> <field name="material_code"/> <field name="material_name"/> <field name="spec"/> <field name="unit"/> </group> <group> <field name="category"/> <field name="cost_price"/> <field name="related_product_id"/> <field name="stock_quantity"/> </group> </group> </sheet> </form> </field> </record>

写XML时最容易翻车的不是结构，而是id唯一性。同一个模块内所有record id混在一个命名空间里，你要是给两个不同模型都定义了test_form，装第二个的时候就会报ID冲突。我的习惯是给记录ID加模型前缀，比如material_form、material_list、material_action，从根上避免撞车。

4.4 权限文件：ir.model.access.csv 与安全组

模型建好了，视图也写了，不配权限的话，界面上根本看不到菜单。权限分两道：模型访问权限（能增删改查哪张表）和菜单/记录规则（能看哪些行）。第一道在 CSV 里配：

id,name,model_id:id,group_id:id,perm_read,perm_write,perm_create,perm_unlink material_management_access_group_user,material management user,model_material_management,base.group_user,1,1,1,0 material_management_access_group_manager,material management manager,model_material_management,base.group_system,1,1,1,1

model_id:id的命名规范是model_加模型名里的点换成下划线。这个反推关系常有人写错，比如material.management对应model_material_management就写错成model_material_management以外的拼写。更常见的问题是把perm_unlink给普通用户也开了，导致业务人员误删关键单据。实施时的建议是：普通用户一律不给删除权限，删除操作由管理员完成，必要的时候再加服务器动作做软删除。

菜单可见性和组绑定也有关系。菜单XML里的groups字段如果没写，所有有模型权限的人都能看到菜单；如果写了groups="base.group_system"，非管理员登录后就看不到入口。很多新手问为什么权限配了还看不到菜单，多半就是菜单上的组过滤忘了写。

4.5 数据迁移：从Excel到Odoo的导入模板与外部ID

数据迁移是实施里最枯燥但最不能出错的部分。导入前我先做两件事：一是把Excel表头改成Odoo的字段名（material_code、material_name这种），而不是中文表头，避免导入时的ID解析混乱；二是在系统里先建好关联数据，比如产品分类、计量单位，让导入时的category/id能对上。

导入外部ID的方式是准备一个data/external_id.csv：

id,module,model m001,material_management,material.management

结合实际导入，系统会优先通过外部ID去匹配已有记录，匹配不到才创建新的。这叫幂等导入，同一个文件反复导入不会生成重复数据。我第一次做迁移的时候没配外部ID，直接按名称匹配分类，结果同一个分类因为前后名称空格的差异生成了两条，后面所有引用都乱了一套，返工了整整一天。后来习惯是先清洗Excel（去空格、统一编码、规范日期格式），再生成外部ID文件，导入一次验证一次。

4.6 权限矩阵与记录规则：多部门协作时的必备设置

中小公司最容易出现的权限需求是：销售想看库存但不能改采购价；仓库能改数量但不能看成本；财务只看订单和发票。只靠ir.model.access.csv做不了行级隔离，需要配合ir.rule记录规则。一个按公司（company）隔离的规则示例：

<record id="material_rule_company" model="ir.rule"> <field name="name">物料按公司隔离</field> <field name="model_id" ref="model_material_management"/> <field name="domain_force">[('company_id', '=', company.id)]</field> <field name="groups" eval="[(4, ref('base.group_user'))]"/> </record>

domain_force里的company.id是Odoo的一个魔法变量，表示当前用户所属公司。加了这条规则后，即使两个公司的账号都有material.management的模型权限，也互相看不到对方数据。记录规则是实施后期最容易引进性能问题的地方，规则里不要写过于复杂的主查询，否则每个列表页都会多跑一大堆额外SQL。

5. Odoo 16实施避坑：权限、时区、缓存与升级的五条血泪记录

5.1 现象：安装模块报External ID not found: ...原因：XML中引用了尚未加载的记录 ID

这个问题在我经手的模拟项目X里出现过不下五次。典型场景是自定义模块里视图先引用了动作material_action，但data列表里动作XML排在视图XML后面。解决方法是调整__manifest__.py的data文件顺序，先加载动作和菜单，再加载表单列表视图。另一个隐藏原因是在别的模块里引用了本模块的记录ID，但本模块还没安装，这时需要在depends里加上那个模块，或者把记录定义挪到被依赖模块中。

5.2 现象：报表和表单里的时间比本地时间早了8小时 原因：Odoo 内部统一用UTC存储时间

Odoo 的Datetime字段存进 PostgreSQL 时默认是UTC时间，界面展示时会按当前用户的语言和时区设置转换。实施时如果只建了数据库，没给用户设置时区（用户 → 偏好设置 → 时区），就会看到所有单据时间对不上。给用户批量设置时区可以用一段简单的Python：

env['res.users'].search([]).write({'tz': 'Asia/Shanghai'})

另外，如果你在代码里直接用fields.Datetime.now()，拿到的是UTC时间，要显示本地时间得用fields.Datetime.context_timestamp(self, fields.Datetime.now())。这个坑特别隐蔽，统计报表里偏差一小时往往就是这里出的问题。

5.3 现象：升级模块完全没反应，重启后还是旧的 原因：Python代码变更需要重启worker，XML视图需要升级模块

在--dev=all模式下改Python模型文件，Odoo会自动reload；但生产环境用systemd服务跑的时候，必须手动sudo systemctl restart odoo16才生效。改XML视图则要在界面里进「应用」找到模块点升级，如果只改文件不升级，你会发现系统用的还是缓存的旧视图。我见过某开发者改了20分钟表单字段，怎么刷新都不变化，最后才发现只重启了服务没升级模块。这一步忘掉的话，市面上80%的「改了没生效」问题都由它引起。

5.4 现象：登录界面卡死或白屏 原因：session被清空或静态资源缓存异常

出现白屏先看浏览器控制台的报错，如果是404加载不到JS文件，多半是Odoo实例的addons_path没写对，导致静态资源目录无法访问。另一个高发原因是部署了反向代理，但没把/web/static的请求转发到Odoo端口，只转发到了根路径，导致前端资源全挂。解决方案是在Nginx站点配置里把/web/static单独location，并且加一条proxy_buffering off。这个配置项能直接影响交互流畅度，尤其在表单加载大量字段时，开着缓冲会让前端频繁卡住。

5.5 现象：数据库备份文件很大，恢复到一个新库后部分模块报错 原因：备份里的模块状态与代码目录不一致

备份恢复不是无脑操作。Odoo的数据库里存了模块状态，恢复后如果目标环境没安装对应模块的代码，界面访问会直接报Module Not Found。正确的做法是恢复后在配置文件里加上--upgrade参数启动一次，让所有模块按代码目录重新对齐版本。但注意，--upgrade全量升级在生产库上很伤时间，一个几百个模块的库可能跑一两个小时，所以平时备份恢复演练建议按模块范围升级，比如只升级stock,sale_management这些核心对象。

6. 进阶：先学会这三个扩展点，后续开发省一半时间

第一个扩展点是模型继承，用_inherit复用现有模型而不是新开一张表。比如给销售订单加一个「项目代号」字段，直接在sale.order上_inherit，再在视图里xpath定位挂载即可。这种方式能让你改动最小，升级官方模块时冲突最少，绝大多数业务微调都该走这条路，而不是把整个视图复制出来改一遍。复制视图意味着官方模块升级时你的视图会一并被覆盖，到时候又得手工合并，得不偿失。

第二个扩展点是QWeb报表。Odoo的打印报表是基于QWeb模板的PDF渲染，实施中「报价单、送货单格式要调整」是高频需求。不用去改底层模板，继承现有模板再替换块就行。在views/report_inherit.xml里写<template id="report_saleorder_document_inherit" inherit_id="sale.report_saleorder_document">，然后通过xpath把要改的段落替换掉。这里有个习惯：报表模板继承的inherit_id最好写模块名.模板外部ID的完整引用，避免不同模块之间存在ID歧义。

第三个扩展点是服务器动作和自动化。Odoo 16的设置菜单里可以直接配自动化动作，不需要写代码就能实现「订单确认后自动创建备货单」「库存低于安全库存时给采购经理发消息」这类操作。实施时先用界面配置跑通流程，再回头看生成的Python代码，理解record.action = 'confirm'这类写法，比一上来就手写代码靠谱得多。我一般会在售后培训里让客户先配两三个自动化动作，把「触发条件-执行动作-报错通知」的逻辑熟练了，后续让他们自己维护系统才不慌。

这三招回访时客户能复述出来，你的实施项目才算真正落地。我做过的方案里，凡是后期需求变更少的，基本都是先在模型继承和自动化动作上多花了两天功夫，而不是急于把界面搭完。一次教训是给某公司做物料审批流，图省事在标准模块上直接改了大量视图，结果官网上线一个季度后升级安全补丁，视图冲突改了三星期。从那以后，凡是能继承解决的，绝不复制原始模板。希望帮到你。

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