Odoo 选哪个订阅？

Odoo 的价格页看起来是在选一个版本，实际需要确定的是两件互相独立的事：能用什么功能，以及系统跑在哪里。两者组合后，决定了这套系统当前能做什么、以后可以改成什么样。

订阅档位本身的调整成本很低——在同一个数据库内改动，功能即时生效或收回。成本较高的是选定之后需要更换数据库的情形。

本文不涉及具体价格。Odoo 按地区分档定价，且价目随时间调整，以签约时官网配置器的实际报价为准。

1. 先回答一个问题

是否需要在系统中安装代码模块？

代码模块指以 Python 编写、部署进系统运行的模块，包括第三方购买的模块和定制开发的模块。

• 不需要 —— 后文关于托管方式的部分可以略过，剩余的判断集中在功能覆盖是否足够。
• 需要 —— 可选托管方式由四种减为两种，后续判断集中在是否具备服务器运维能力。

这个问题具有决定性，原因是 Odoo 的两种共享云托管在架构上不开放文件系统访问。没有可供部署代码的位置，属于架构限制，不通过付费档位解除。

2. 两条轴：套餐与托管

Odoo 的产品结构由两条独立的轴交叉构成。将两者混为一谈，是选型偏差的主要来源。

第一条轴：套餐，决定可用功能范围。

• Standard —— 不含 Studio，无外部 API 访问，不支持多公司。
• Custom —— Studio、多公司、外部 API 全部可用。

代码模块不在这条轴上，它由托管方式决定。但两条轴在这里有一处交叉：Standard 只能配共享云，而共享云装不了代码模块——因此选 Custom 是安装代码模块的必要条件，不是充分条件。

第二条轴：托管，决定系统运行在哪台服务器上。

1. Odoo 官方共享云（Online） —— 多租户环境，备份、安全、升级由 Odoo 负责。
2. Odoo.sh —— 官方 PaaS，通过 Git 推送代码，自带 staging 环境。
3. 自部署（Self-Hosting） —— 运行在自有服务器或 VPS 上。

Standard 套餐只能搭配共享云。Custom 套餐三种托管方式均可选。

此处存在一个命名重合：Custom 套餐下的共享云托管，官方名称为 Standard Cloud Hosting，与套餐档位中的 “Standard” 不是同一概念。前者功能为 Custom 全套，区别仅在于托管于共享云、不能部署代码模块。

2.1 多个业务板块：同库多公司，还是多个数据库

存在多个业务板块或多个法律实体时，这一选择直接影响订阅费用，因此需要在选型阶段一并确定。

计费口径：

• 一份订阅对应一个数据库。同一数据库内启用多公司功能，不因公司数量增加订阅费用。
• 每增加一个独立数据库，需要一份独立订阅，费用叠加计算。
• 标准版数据库启用多公司功能，会触发套餐升级至 Custom。

两种结构的差异：

	同库多公司	多个数据库
订阅费用	一份	每库一份
科目表 / 产品 / 联系人	可共享，也可按公司区分	各库独立，无法共享
跨业务合并报表	系统内直接出	需在系统外汇总
数据隔离	依赖权限配置	物理隔离
故障影响范围	全部公司	单个业务
升级与维护	一次	每库各一次

3. 四种付费组合

对比维度	Online 标准版	Custom + Standard Cloud Hosting	Custom + Odoo.sh	Custom + 自部署
所属套餐	Standard	Custom	Custom	Custom
服务器位置	Odoo 官方云，多租户	Odoo 官方云，多租户	Odoo 官方 PaaS	自有服务器 / VPS
能否安装代码模块	不能	不能（无文件系统访问）	能，Git 推送	能
Studio	无	有	有	有
多公司	无	有	有	有
外部 API 访问	无	有	有	有
版本升级执行方	Odoo	Odoo	Odoo 平台协助，一键流程	自行执行
备份 / 安全 / 监控	Odoo 负责	Odoo 负责	Odoo 平台负责	自行承担
许可费档位	最低档	Custom 档	Custom 档	Custom 档
基础设施费用	含在套餐内	含在套餐内	按 worker、存储、staging 计	自行承担服务器费用
数据位置	由 Odoo 决定	由 Odoo 决定	Odoo 云账户内，区域有限	自行指定
root / 系统底层权限	无	无	无 root，系统包受限	完全 root

3.1 共享云上的扩展路径：外部 API

选择共享云托管后，代码模块这条路关闭，但 Custom 档解锁的外部 API 仍然可用。这种方式把逻辑放在 Odoo 之外运行，通过 API 读写数据，而不是把代码装进系统内部。

外部 API 不限于共享云，Odoo.sh 与自部署同样可用，它是一种通用的扩展架构。两者的分界在于逻辑是否需要进入事务：

• 需要阻止某项操作发生、需要在录入当下出现在界面上、需要参与计算字段或校验 —— 由模块实现。外部程序在事务之外，只能在操作完成之后作出反应。
• 数据同步、批量处理、报表、与外部系统对接 —— 外部 API 适用，且不涉及大版本升级时的模块移植工作。

需要注意的是，外部 API 的接口面就是 Odoo 的数据模型。字段被移除或方法签名变更时，外部程序同样会失效。差别在于失效的位置：模块在升级加载时失败，可在测试环境中发现；外部程序在下一次调用时失败，可能发生在生产环境的运行期间。

4. 自部署与官方托管的差异构成

Custom 套餐下的三种托管方式，许可费按用户计价，三者相同。因此自部署与官方托管的差异不体现在许可费上，而集中在以下三项：

1. 基础设施费用 —— 自部署承担服务器费用，不再产生 Odoo.sh 的 worker、存储与 staging 计费。
2. 运维责任 —— 备份、安全加固、监控、版本升级的执行，由 Odoo 平台转移至自身或自身的开发者。Odoo.sh 环境下这些由平台承担，并附带官方支持渠道。
3. 数据位置与系统权限 —— 自部署可自行指定数据存放位置与网络路由，并拥有完整 root 权限，可安装任意系统依赖。Odoo.sh 无 root 权限，可用系统包受限。

自部署适用于对数据位置有明确要求、或需要非常规系统依赖、且具备独立运维能力的场景。不具备独立运维能力的企业，需将运维责任的承接方式一并纳入评估。

5. 社区版

除上述四种付费方案外，另有免费开源的社区版（Community）：自行部署，无许可费。

其功能边界如下：

• 不含 Studio，配置类改动需通过开发实现
• 不含企业版模块，OCA 社区提供部分替代实现
• 无官方支持渠道
• 每次大版本升级为独立的付费开发工作
• 官方仅维护最近数个大版本，更早版本不再提供安全补丁

适用范围

以下两个条件满足其一即可：

1. 具备自有 IT 运维，且能长期承接维护责任。 承接方变更后的接手安排，属于选型阶段需要确定的事项。
2. 不具备运维能力，但对历史数据留存无要求，且能够承担系统故障带来的损失。 数据丢失、停机、缺陷长期不修复、安全补丁缺失，在这一前提下属于可接受的结果。

两个条件都不满足时——既无人承接维护，又需要会计凭证、库存台账、客户历史长期可查可核对——零许可费省下的部分，需要与数据风险一并纳入总成本评估。

6. 用户数的计费口径

• 内部用户 —— 登录后台执行业务操作的账号，按账号数量计费，与登录频率无关。
• 门户用户（Portal） —— 外部人员通过门户查看与自身相关的单据（订单、报价、发票等），不计入内部用户数、不产生费用。

统计时以需要登录后台的账号数量为准。

7. Studio 的适用范围

Studio 配置的产物存储在数据库中，属于数据，不属于代码。由此产生以下特性：

1. 不纳入 Git 版本控制。 无变更历史，无法进行 code review。
2. 配置点分散。 一项需求涉及的字段、视图、自动化动作、访问权限分别存放在不同位置。后续修改需先定位全部相关配置点，并确认改动的连带影响范围。
3. 移除时可能留有残留配置。 需逐一定位并删除各配置点。
4. 表达能力受限。 多步骤计算、条件分支、跨模型联动的业务规则超出 Studio 的表达范围。

同等需求通过自建模块实现时，逻辑集中于少数文件，纳入版本控制，可编写测试，卸载后不残留配置。

适用边界：Studio 适用于轻量、结构简单的配置类改动，例如新增字段、调整视图、配置提醒。需求出现条件分支或跨模型联动结构时，适合转为模块实现。

8. 版本升级的责任边界

对比表中”版本升级执行方”一行的实际分界如下：

• 标准数据库的升级 —— 在官方服务范围内。
• 自定义模块、Studio 配置、第三方模块 —— 不在官方服务范围内。

第三方模块按版本单独计费，且以作者发布对应版本为前提。作者未发布新版本时，需自行接手维护或移除该功能。

因此大版本升级的总成本中，Odoo 官方收取的部分通常不是主要构成。

9. 更换数据库的成本

订阅档位在同一数据库内调整，成本较低。成本较高的是更换运行环境、更换数据库、迁移数据。

1. 机制上不存在转换脚本。 迁移过程为导出备份、在新环境恢复。数据库本身的恢复通常在较短时间内完成。

2. 方向不对称。 向限制更少的环境迁移（共享云 → Odoo.sh → 自部署）可以走通，目标环境不限制代码模块；向限制更多的环境迁移时，源数据库中存在任何自定义模块即无法完成。

3. 主要成本在系统周边。 数据库恢复完成后，仍需处理：

   • 系统 URL 变更，所有对外集成的回调地址需重新配置
   • webhook 需在对方平台重新登记与验证
   • API key、邮件服务器、支付网关等凭证需重新设置
   • 定时任务需确认恢复运行
   • 外部系统中保存的指向旧地址的配置需逐项排查

   这部分工作量与集成数量相关，且需在业务持续运行的前提下完成。

4. 企业版转社区版为单向操作。 企业版模块在数据库中建立的表与字段，卸载后不会完整移除，残留会使社区版环境处于不确定状态。该方向通常的做法是新建数据库重新配置，历史数据另行处理。

选型阶段的判断依据不是”以后能否更改”，而是“以后更改时是否需要更换数据库”。需要更换的，成本高；不需要的，成本低。

10. 三种常见误选

1. 选定 Custom 套餐后搭配共享云托管，随后发现无法安装模块。 Custom 套餐解锁了功能，但共享云不开放文件系统访问。需要安装代码模块时，可选项只有 Odoo.sh 与自部署。

2. 以节省许可费为目标选择自部署。 Custom 套餐三种托管方式许可费相同。自部署减少的是基础设施费用，同时接管全部运维责任。

3. 使用 Studio 构建复杂业务逻辑。 配置阶段推进较快，差异出现在后续修改阶段：配置点分散、无变更历史、连带影响范围需重新排查。

11. 按情况对号入座

情况	建议方向
流程标准，无定制需求，无 IT 人员	Online 标准版
需要 Studio / 多公司 / API，不需要代码模块	Custom + Standard Cloud Hosting
需要代码模块，不具备独立运维能力	Custom + Odoo.sh
需要代码模块，具备运维能力，对数据位置有要求	Custom + 自部署
具备长期 IT 运维承接能力；或不具备运维能力但可承担系统故障损失	社区版自部署

12. 这篇没有回答的问题

订阅与托管确定的是系统的能力边界和运行位置，还没有涉及系统里装的是什么。数据库开出来之后，第一批要建的是主数据——产品、联系人、科目、仓库。业务单据全部引用主数据而成立。

配置从这里开始，问题也从这里开始：

用户账号建好之后，每个人默认能看到什么？

产品成本、联系人这类主数据字段，默认可见范围是全部内部用户。这一默认值与 Odoo 的数据引用结构有关：主数据承载业务规则集，单据在生成时需要读取其中的字段才能完成计算与校验，可见范围因此被操作需求推至最宽。

这个范围是否与企业实际的信息边界一致，需要逐项确认。

（下一篇：Odoo 装好之后，员工的默认权限是什么？）