导言
在 Odoo 中，模型决定了数据在数据库里的组织方式。几乎所有日常业务信息——从订单、发票到客户联系人——都有对应的模型来保存和管理。
无论你是开发工程师还是业务顾问，理解 Odoo 的模型概念都是基础技能。模型不仅定义字段，还描述记录之间的关系与内置业务规则。
本文聚焦 Odoo 中一项核心模型：res.partner。无论你是在做模块开发、第三方系统对接，还是搭建业务流程，这个模型都会频繁出现。
什么是 res.partner 模型
res.partner 用来表示联系人、客户、供应商以及公司主体，是保存“业务往来方”信息的中心表。
这个模型被几乎所有核心应用引用：销售、客户关系管理、财务、采购和电商都依赖 res.partner。创建客户、线索或供应商时，系统要么创建新的 partner 记录，要么关联已有记录。
res.partner 定义在基础模块里，其他模块通过 Odoo 的模型继承机制在此基础上扩展。例如 CRM 会增加与线索相关的字段，会计模块会加入信用和付款条款字段，各模块按需扩展而不重复核心结构。
模型中的关键字段
下面列出 res.partner 中常用且重要的字段，熟悉它们能让你更高效地处理联系人、客户与供应商数据。
1. name
类型：Char。存储记录显示名称——公司记录是公司名称、自然人记录是完整姓名。这个字段出现在大多数视图里，是识别伙伴的主要字段。
2. create_date
类型：Datetime。记录创建时间，由 Odoo 自动维护，便于报表和审计使用。
3. write_date
类型：Datetime。记录最后一次修改时间，同样自动维护，用于追踪更新历史。
4. email
类型：Char。主要电子邮件地址，用于沟通、发票和门户登录。Odoo 在可能情况下会校验邮箱格式。
5. phone
类型：Char。主电话号码，在联系人表单和通讯流程中显示。
6. mobile
类型：Char。移动电话，常用于短信通知或紧急联系。
7. street
类型：Char。地址第一行，构成发票和运输单据的地址块的一部分。
8. street2
类型：Char。地址第二行，用于楼层、单元号或补充地址信息。
9. city
类型：Char。所在城市或地区，地址格式会随国家有所不同。
10. zip
类型：Char。邮编，用于地址校验与配送费计算。
11. state_id
类型：Many2one（res.country.state）。州/省字段，会根据 country_id 过滤；并非所有国家适用。
12. country_id
类型：Many2one（res.country）。国家字段，会影响地址格式、税务规则与本地化逻辑。
13. is_company
类型：Boolean。标识此记录是公司还是个人。公司可以包含子联系人，个人可通过 parent_id 关联到公司。
14. parent_id
类型：Many2one（res.partner）。用于把联系人关联到公司，支持公司-联系人层级关系；在设置后部分字段可从父级继承。
15. child_ids
类型：One2many（res.partner）。parent_id 的反向关系，列出归属某公司的所有联系人，便于从公司跳转到其成员。
16. company_id
类型：Many2one（res.company）。多公司环境下表示该 partner 属于哪个公司，影响可见性和权限。
17. vat
类型：Char。税号或增值税号，会根据国家格式校验。税务和发票合规依赖此字段。
18. customer_rank
类型：Integer。标识是否为客户及其活跃度，系统在发生销售时会自动增加此值，用于筛选和报表优先级。
19. supplier_rank
类型：Integer。表示供应商状态，在产生采购或供应商账单时递增，便于识别供货方。
20. user_id
类型：Many2one（res.users）。负责人或销售人员，用于 CRM 分配、销售团队统计与活动分工。
21. type
类型：Selection。子联系人地址类型：联系人、发票、收货或其他。决定文档使用哪个地址，仅对有父公司的联系人有效。
22. ref
类型：Char。内部参考码，常用于与外部系统对照或自定义编号规则。
23. website
类型：Char。网站地址，在联系表单和电商场景中使用。
24. comment
类型：Html。内部备注，仅内部可见，常用于销售说明或特殊指示。
25. active
类型：Boolean。软删除开关，设为 False 时记录归档并在默认视图中隐藏，但不会物理删除。
26. lang
类型：Selection。首选语言，系统发送邮件和文档时可据此翻译，且可从父级继承。
27. image_1920
类型：Binary。伙伴头像或公司标志，Odoo 保存多种尺寸，展示于表单、报表和网站。
28. category_id
类型：Many2many（res.partner.category）。用于打标签和分类，便于市场分组、筛选与营销活动。
该模型在企业流程中的应用场景
1. 销售与 CRM
销售人员在创建报价时会选择 res.partner 中的客户；同一条伙伴记录可以贯穿线索、机会到订单。customer_rank 与 user_id 决定分配与报表统计。
2. 发票与财务
发票和供应商账单引用 partner 的账单地址，vat 字段影响税金计算，信用额度和付款条款通常记录在伙伴层级。
3. 采购与供应商管理
采购订单与供应商账单同样关联 res.partner，supplier_rank 用于识别活跃供应商，buyer_id（或 user_id）用于分配负责人以便供应商管理。
4. 电商与门户
网站用户注册时会生成 partner 记录，系统用该记录管理订单、报价与门户访问，地址与联系方式都来源于 partner。
5. 多公司与合并场景
在多公司环境中，同一法人实体可能存在多个公司范围内的 partner 记录，company_id 与公司间规则决定数据如何共享与合并。
开发者如何扩展该模型
开发者通过多种方式扩展 res.partner，其中模型继承是最常用的机制。
模型继承
在自定义模块中使用 _inherit = 'res.partner' 来扩展该模型，可以新增字段、重写方法或添加约束。通过继承保持自定义代码在独立模块中，有利于后续升级维护。
新增字段
在继承的模型中定义所需字段，选择合适的字段类型（Char、Many2one、Boolean、Integer、Text、Selection 等）。在多公司环境下，考虑字段是否应关联公司（company-dependent）。
Python 扩展点
可重写 create、write、unlink 等方法来插入业务逻辑，记得在合适位置调用 super()。处理计算字段时需注意依赖关系与触发逻辑。
Odoo Studio
Odoo Studio 允许无需写代码就添加字段和简单自定义，适合快速原型。但对复杂逻辑或长期可维护性，建议使用自定义模块开发。
最佳做法
- 按正确顺序建立公司与联系人层级：先创建公司，再用 parent_id 添加联系人。
- 设置 country_id 以保证地址格式和税务规则正确适配当地规范。
- 当你需要按“商业实体”汇总（例如信用额度或报表）时，使用 commercial_partner_id 来获取顶层主体。
- 做 API 集成时推荐使用 XML-RPC 或 JSON-RPC 接口，res.partner 在 API 中可完全访问。对外部 ID 的映射需设计好以避免重复。
- 为自定义字段使用 x_ 前缀或加模块前缀命名，避免与未来 Odoo 版本的字段冲突。
常见错误
- 创建重复伙伴而不先搜索已有记录。应使用 email_normalized、ref 等字段做去重判断。
- 混淆 parent_id 与 company_id。parent_id 是公司-联系人层级链接，company_id 用于多公司环境中主体归属。
- 未给子联系设置 type。发票和收货地址若类型错误会导致单据上使用不正确的地址。
- 重写核心方法却不调用 super()，这会破坏其他模块的行为并增加升级风险。
- 为必填自定义字段不提供默认值，导致已有记录在升级时校验失败。
总结与下一步
res.partner 是 Odoo 的关键模型，负责保存联系人、客户与供应商信息。掌握其字段与扩展方式能让你更好地配置、定制与集成 Odoo。
无论你是负责业务流程设计的顾问，还是编写自定义模块的开发者，熟悉 res.partner 都能节省大量时间并降低出错概率。
需要帮助实施 Odoo 吗？
Dasolo 为企业提供 Odoo 实施、定制与优化服务，擅长 API 对接与模块开发。我们的团队对 Odoo 的数据架构与核心模型（例如 res.partner）有深入理解。
如果你在 Odoo 实施、定制或对接方面需要支持，我们可以提供专业帮助。 安排演示 与我们讨论你的项目。