本文内容
Odoo 客户门户：什么时候配置、扩展或自建？
客户已经可以下载发票。现在，采购人员希望由另一位同事批准订单，然后才能确认。先查清楚：现有 Odoo 配置究竟能落实这条规则的哪些部分？
是否扩展 Odoo 客户门户，应由客户需要执行的操作和账户关系决定。先演示原生流程。如果缺失的规则属于 Odoo 业务记录，就评估范围明确的模块扩展。如果客户操作跨越多个系统，或界面需要独立维护，再考虑单独的门户。无论选择哪种方式，每条访问路径都要接受相同的授权检查。
资料核对日期：2026 年 11 月 5 日。产品事实依据 Odoo 20.0 官方文档源文件。下文的经销商场景和可下载验收表属于设计建议。我们没有在实际运行的 Odoo 数据库上执行这些测试。
Odoo 原生客户门户已经能做什么？
原生客户门户支持特定的文档操作和自助功能。应在实际安装的版本及配置上演示它们。调整版式可能只需要修改设置；让另一人获得订单审批权，则是在改变业务规则。先要求提供该规则的实现证据，再判断是否需要定制开发。
Odoo 的门户文档列出了订单、发票和账户相关操作。其中关于阅读、查看的描述，并不表示客户在门户中永远不能执行操作。在线签名文档说明了启用后由客户确认报价的流程；门户账户更新文档则介绍了特定的联系信息、付款及安全设置修改。
这些都是应用定义的操作。它们不能证明客户拥有普遍编辑业务记录的权利，也不能证明采购方要求的审批链已经存在。检查操作人身份和生成的记录，然后让同一个人尝试一次本应禁止的操作。
对每项需求，记录原生演示证明了什么、还缺什么。没有测试过的功能就标为未测试。“包含客户门户”无法回答谁可以批准同事修改后的订单。
需要区分哪些公司与联系人关系？
把联系人的角色分别绑定到客户账户和允许的操作。Odoo 中的运营公司、客户的法律实体及其分支机构，在需求中是不同概念。共用电子邮件域名或上级联系人关系，不能证明某人拥有审批权。把一个人加入审批路径之前，应明确批准其账户归属。
Odoo 文档说明了如何通过联系人授予和撤销门户访问权限。这提供了账户管理机制。验收时仍然要确认：在实际配置中，每位获邀联系人究竟可以访问哪些记录、执行哪些操作。
以一家服务客户账户 A 和 B 的经销商为例。采购员 A 为 A 准备采购申请；审批员 A 在约定额度内批准 A 的采购；财务查看者下载 A 的发票。区域员工则需要分别获得两个账户的授权关系。
| 角色 | 允许范围 | 需要证明的边界 |
|---|---|---|
| 采购员 A | 准备 A 的采购申请并查看进度。 | 要求职责分离时，不能批准自己的申请。 |
| 审批员 A | 批准 A 当前符合条件的申请。 | 不能批准 B 的申请，也不能批准从未审核过的新版本。 |
| 财务查看者 A | 阅读并下载 A 获准查看的财务文件。 | 不能修改订单，也不能获取 B 的附件。 |
| 受委派管理员 A | 申请或管理约定范围内的 A 账户成员关系。 | 没有额外权限时，不能分配更强角色或其他账户。 |
| 区域员工 | 使用分别获得批准的 A、B 角色。 | 切换账户时，权限和草稿数据不能随之转移到另一账户。 |
创建账户与授予业务权限需要分别检查。Odoo 的客户账户配置文档介绍了邀请设置及跨网站共享账户。这两项设置都不能证明上面的账户与操作矩阵已经实现。支持人员和自动集成使用的技术身份，也应纳入同一审查。
应该配置原生门户、扩展 Odoo，还是另建门户？
选择能够执行约定客户流程、且维护负责人能够长期管理的最小方案。已得到演示证明的原生能力适合通过配置使用。紧贴 Odoo 记录的缺失规则适合模块扩展。只有跨系统体验及其价值足以承担另一套应用的运行成本时，独立前端才有充分理由。
| 方案 | 适合的理由 | 批准前需要的证据 | 持续责任 |
|---|---|---|---|
| 配置原生门户 | 已安装应用能够执行所需操作并支持相应关系。 | 完整客户流程及相关拒绝访问测试。 | 负责配置、邀请、回归检查和支持。 |
| 扩展 Odoo | 范围明确的权限、审批或文档规则属于 Odoo 事务。 | 指定版本中的模块行为、服务端约束和升级测试。 | 在依赖变化及升级过程中维护模块。 |
| 建设独立门户 | 客户需要跨越 Odoo 与其他系统的流程，或独立发布的界面。 | 身份映射、授权命令、数据源归属和故障恢复。 | 运行另一套应用，包括集成和发布控制。 |
托管方式可能限制扩展路径。Odoo Online 不支持自定义模块及 Apps Store 模块。这项托管决策可参阅从 Online 转向 Odoo.sh 的集成判断。设计外部后端前，还应查看现有的Odoo API 架构限制分析。
单独建设门户，并不会自动把难以执行的规则从 Odoo 中移走。如果内部用户、导入程序或其他集成也能修改订单，仅在浏览器里加限制就留下了其他入口。应把必须成立的业务条件放在所有相关操作都要遵守的位置，并明确测试每条路径。
让各家供应商演示相同的流程及异常情况。更广泛的采购判断可参考定制软件与标准软件的选择指南。如果 Power Pages 也是候选方案，它的外部用户成本模型需要单独计算，不能作为本次 Odoo 扩展的报价依据。
怎样让客户审批规则真正生效？
将审批绑定到操作人、客户账户以及已经审核的记录版本，并规定哪些变化会让审批失效。“批准”按钮只是界面。服务器接受状态转换时，必须验证操作权限及当前记录，而不能仅仅相信前端提交的批准结果。
假设经销商要求超过示例门槛 5,000 欧元的采购由第二人批准。先确定金额是否含税、适用哪个汇率，以及恰好等于 5,000 欧元时如何处理。还要明确谁可以修改门槛、谁可以批准替代审批人。Odoo 无法从“添加审批”四个字中推断这些业务决定。
采购员提交了金额为 5,200 欧元的第 7 版申请，审批员 A 审核了这一版。确认之前，采购员更改数量，形成金额为 6,400 欧元的第 8 版。根据这里建议的规则，原审批应失效，并要求重新审核。服务器接受状态转换的那一刻，必须比较已批准版本和当前版本。
还应确定被拒绝后能否修改申请，以及取消时是否释放预留。委派权限到期后，队列中的动作也需要明确处理规则。保留审批决定、当时审核的版本，以及最终生成记录的引用。
这是采购方内部的政策，与卖方报价签名流程不同。如果店铺基于 Shopify，可另看Shopify B2B 订单审批比较，但其中的平台能力不能直接套用到 Odoo。
上线前如何测试委派访问权限？
为每项允许的操作配上一项同一身份必须被拒绝的操作，再检查最终业务记录。使用受保护的测试环境和明确的测试账户。测试应包括直接请求文档、更换对象标识、撤销成员关系及修改已审核输入，而不能仅观察界面隐藏了哪些按钮。
| 检查 | 按照示例政策应出现的结果 | 证据 |
|---|---|---|
| 财务查看者 A 下载获准查看的 A 发票。 | 返回正确文档。 | 身份、账户、记录引用和文档身份。 |
| 同一人直接请求 B 的发票或附件。 | 不泄露文档或受保护元数据。 | 响应和服务端授权结果。 |
| 采购员 A 提交超过门槛的申请。 | 申请等待有权限的第二人批准。 | 业务状态及不存在越权确认的证据。 |
| 已审核申请在确认前发生变化。 | 旧审批不能授权新版本。 | 版本比较和重新审核要求。 |
| 员工成员资格已撤销，但会话仍然打开。 | 下一次受保护操作遵守撤权结果。 | 撤权时间、请求身份和被拒绝动作。 |
| 同一版本同时收到两个审批请求。 | 只产生一次预期业务效果。 | 最终记录状态及关联请求引用。 |
可下载建议的门户权限验收矩阵。每项用例的初始状态都是 NOT_RUN。请用已经批准的政策替换示例角色和门槛，补充安装版本、模块修订版本及实际执行证据。这是一份测试说明，不是安全扫描结果。
无论选哪种实现方式，都使用相同政策。每个拒绝访问用例都应配对一个能够成功的授权操作。如果所有请求都被阻止，仍然不能证明门户按要求工作。管理员演示也不能证明客户之间的数据隔离。
哪个系统负责文档以及失败的操作？
为每个操作确定权威系统，并规定该系统不可用时门户显示什么。客户需要区分“请求已提交”和“订单已确认”。支持团队则需要能够核对不确定结果，避免重复执行实际上可能已经完成的业务动作。
对于跨系统门户，每项操作都应有简短约定：源记录标识、客户账户标识、数据新鲜度要求、允许的命令、响应状态及恢复负责人。如果配送状态来自仓储系统、发票状态来自 Odoo，应分别标注来源和更新时间。
文档下载路径需要授权检查，链接到它的页面也需要。还应检查缓存副本、生成的 PDF、导出及搜索结果。即使订单列表范围正确，后续附件请求忘记账户关系，仍然会留下缺口。为客户管理分配负责人，并保留审计记录。
实施需求说明应包含什么？
需求说明应描述完整客户流程、权限矩阵、异常状态及验收证据，同时指定支持和升级负责人。用这些范围比较各家方案，包括测试责任和持续工作。这样才能看出表面相似的报价是否承担了同样的业务要求。
- 明确第一个完整流程。例如，受邀采购员准备采购，审批员审核，采购员查看已接受的结果。
- 附上关系模型。覆盖多个账户、委派管理、离职和临时权限。
- 写明必须成立的业务条件。说明哪些修改需要重新审批，以及每条写入路径如何执行规则。
- 指定验收证据。要求允许和拒绝操作可重复执行，检查文档身份及最终记录。
- 分配持续工作。包括模块或连接器升级、支持访问、监控和可重复的发布检查。
- 保留交接资料。让维护团队能够获得源代码、配置、账户映射和运行说明。
要求供应商针对同一验收矩阵报价。如果某份报价排除了委派管理或不确定写入的恢复，应先记录这些排除项，再判断它是否真的更便宜。
我们会先实现什么？
我们会先实现一个完整客户流程及其权限和故障检查。原生门户满足约定政策的部分，优先使用原生能力。针对已经证明的缺口扩展。只有新增客户体验有明确负责人和可信维护计划时，才委托建设独立应用。
Wavect 的客户门户开发服务从客户需要执行的操作出发。讨论范围时，请带上人员与账户矩阵，以及一项无法满足需求的原生演示。它们有助于明确开发究竟需要改变什么。