每个 Odoo 项目最终都会遇到同一个问题：标准流程已经很接近，但还不完全符合业务需求。是应该修改某项设置、打开 Odoo Studio，还是请开发人员编写自定义模块？这个答案会对成本、稳定性，尤其是升级，产生长期影响。
在 1CBMS，我们在每个实施项目中都遵循一条简单的规则：先配置，再 Studio，最后才是自定义模块。沿着这个阶梯每往下走一步，灵活性都会增加，但企业在系统整个生命周期内必须拥有并维护的东西也随之增加。
关于资料来源：本文依据 Odoo 19.0 版官方文档编写。菜单和选项可能因版本、版本类型和托管方式而不同，因此在更改生产环境之前，请务必先在测试数据库中确认其行为。
第一层：配置优先
Odoo 的每个应用都自带大量设置、选项和可配置记录。许多听起来像定制的需求，实际上是尚未开启的标准功能，例如额外的工作流步骤、单据布局，或启用某项功能后才会出现的可选字段。
在为 Studio 或代码编写任何规格说明之前，请与该流程的关键用户一起完成以下检查：
- 查看所涉及的每个应用的设置页面，了解每个选项会启用什么。
- 检查需求是否可以通过阶段、标签、团队、作业类型或电子邮件模板等可配置记录实现。
- 使用公司的单据布局设置来处理徽标、颜色、字体和页脚，而不是编辑报表模板。
- 询问业务方能否调整流程以适应标准流程，因为标准流程由 Odoo 负责测试和升级。
配置是拥有成本最低的一层。它属于标准产品的一部分，会在升级过程中被延续下来，也不会产生需要有人维护的单独代码库。
第二层：Odoo Studio 能做什么
Odoo 文档将 Studio 描述为一个无需编程知识即可定制 Odoo 的工具箱。在您想要修改的应用和模型页面上，点击“切换 Studio”图标即可打开，点击“关闭”按钮即可退出。
根据官方文档，Studio 涵盖以下方面：
- 字段：文本、整数、小数、货币、日期、复选框、选择、文件和图片等简单字段，以及 Many2One、One2Many、明细行、Many2Many、标签和关联字段等关系字段。
- 视图：表单、活动、搜索、看板、列表、地图、日历、同期群、甘特图、数据透视表和图表视图。
- 模型和应用：从零开始构建的新模型，并提供沟通栏、管道阶段、标签、归档和明细行等建议功能以加快创建。
- 自动化规则：基于值更新、电子邮件事件、时间条件、记录创建或删除、界面变化以及外部 webhook 的触发器。
- 审批规则：附加在按钮上的签核步骤，审批人可定义为用户、组或两者兼有。Studio 还涵盖 webhook 和安全规则。
- PDF 报表：在报表模板中编辑静态文本，插入动态字段、表格、列和图片；请注意，编辑报表页眉或页脚会影响所有报表。
当您通过拖放方式修改视图时，Studio 会自动创建相应的继承视图和 XPath，而不是覆盖标准视图。所有 Studio 工作都汇集在数据库中名为 studio_customization 的模块里，该模块可以导出为 ZIP 文件并导入到另一个数据库。
Studio 是 Odoo Enterprise 应用。官方页面还指出，在采用标准版定价方案的数据库上安装 Studio 会触发升级到定制版方案，因此在启用之前，请先与您的 Odoo 客户经理确认其商业影响。Community 数据库不包含 Studio；在 Community 中，超出配置范围的任何内容都需要通过开发者模式下的技术设置或模块来完成。
第二层续：Studio 的局限
Studio 功能强大，但文档本身也指出了每个项目都应重视的若干局限和风险：
- 字段创建后，其技术名称无法在 Studio 中更改；自定义字段必须至少保留 x_ 前缀，Studio 字段使用 x_studio_ 前缀。
- 活动视图和报表中的条件块只能通过编辑 XML 来修改，这需要开发者模式。
- 不建议直接编辑标准视图或继承视图，因为这些更改会在更新或模块升级时被重置并丢失。
- Odoo 强烈建议复制标准报表并编辑副本，并提醒直接修改报表 XML 可能在升级时引发问题。
- 自动化规则中的“执行代码”动作会运行 Python，文档说明自定义代码的维护不包含在标准版或定制版方案中，需要另行付费。
- webhook 应与开发人员或技术岗位人员一起设计，因为配置不当的 webhook 可能会扰乱数据库。
- 导出的 Studio 定制只能导入到 Odoo 版本相同且已安装相同应用和模块的数据库中。
在实践中，Studio 非常适合数据采集、布局、简单自动化和审批。一旦被用来把真正的编程隐藏在无人记录的 XML 编辑或“执行代码”动作中，它就会变得有风险。
第三层：何时有理由开发自定义 Python 模块
自定义模块是一个独立的代码库，通过模型、视图、安全设置、数据文件和 Python 逻辑来扩展 Odoo，并使用与 Odoo 自身应用相同的框架构建。当需求超出配置和 Studio 能够清晰表达的范围时，它就是合适的工具。
我们建议使用自定义模块的典型情形包括：
- 需要自动化测试和版本控制的复杂业务规则、计算或约束。
- 需要健全的错误处理、重试和日志记录的外部系统集成。
- 对标准业务逻辑的更改，例如单据如何验证或数值如何计算，而不仅仅是显示方式的变化。
托管方式在这里至关重要。官方文档指出，Odoo Online 不兼容自定义模块或 Odoo 应用商店中的模块。自定义模块需要 Odoo.sh 或本地部署，因此托管决策和定制策略必须一并制定。
各选项对升级的影响
- 配置：属于标准产品的一部分，由标准升级流程迁移。
- Studio：Odoo 文档中描述的升级服务包括升级使用 Studio 应用创建的所有定制，前提是 Studio 已安装且其订阅有效。
- 自定义模块：在这些模块推出适用于目标 Odoo 版本的版本之前，包含自定义模块的数据库无法升级，而使其兼容是模块维护者的责任。
Odoo 关于升级定制数据库的指南建议：冻结开发；检查哪些自定义功能现已由系统原生提供；确保每个模块都能在目标版本的空数据库上顺利安装；为重命名的模型、字段和外部标识符编写升级脚本；并在触及生产环境之前演练升级。
无论哪一层，都要对升级后的数据库进行全面测试。文档建议端到端测试业务流程，包括集成、自动化动作、服务器动作和报表，并提醒测试数据库已经过中和处理，计划的动作和外发邮件均被禁用。
治理：让定制始终处于掌控之中
定制很少在第一天就出问题。问题往往出现在多年以后，那时已经没有人记得某个字段为何存在，或是谁编写了某条自动化规则。一套轻量的治理模式可以避免这种情况。
- 维护一份定制登记册，列出每个 Studio 字段、视图更改、自动化规则、审批规则、报表和自定义模块，并注明负责人和业务原因。
- 所有更改先在测试或预发布数据库中进行，再通过受控流程迁移到生产环境。
- 仅允许经过培训的管理员使用 Studio 和开发者模式；文档本身也提醒，某些开发者工具属于高级功能且存在风险。
- 每次升级前审查登记册，并淘汰新版本已原生覆盖的定制。
- 将自定义模块代码连同测试一起纳入版本控制，并确保为其安排了维护。
可在研讨会中使用的决策矩阵
当出现新需求时，我们按顺序逐一回答以下问题，并在第一个能够满足需求的层级停下。
- 标准设置、可配置记录或流程调整能否满足需求？使用配置。
- 是否是新字段、视图布局更改、简单自动化、审批步骤或报表措辞修改？使用 Studio。
- 是否需要 Python 逻辑、自动化测试、复杂集成或跨数据库复用？使用自定义模块。
- 数据库是否在 Odoo Online 上？请将范围限定在配置和 Studio 之内，或先规划迁移到 Odoo.sh 或本地部署。
1CBMS 如何为您提供帮助
1CBMS 帮助埃及和伊拉克的企业设计贴近标准的 Odoo 19 Enterprise 解决方案。我们通过差异分析研讨会区分配置与真正的差距，规范地构建 Studio 定制，在确有需要时开发和维护自定义模块，并编制定制登记册和升级测试计划，确保您的系统易于维护。欢迎通过 www.1cbms.com 联系我们，审查您现有的定制或规划新的实施项目。