版本间兼容性（Odoo 10–19）

MCP 服务器会根据检测到的版本、版本类型和部署方式来解析模型名、字段名和能力。 权威且可验证的来源是仓库中的 deltas 映射表 （server/src/odoo_mcp/compat/deltas.py）； 本页只是它的摘要。

检测

• 版本 — common.version() 的主版本整数（server_version_info[0]，或从 server_version 解析得到），约束在 10–19 之间。
• 版本类型 — 版本字符串中的 +e 后缀；若无，则探测 web_enterprise 模块（ir.module.module）；若仍无，则为 unknown。
• 部署方式 — 主机为 *.odoo.com ⇒ saas，否则为 onprem。

模型重命名

现代名称	历史名称	边界
account.move	account.invoice	v13 新增
account.move.line	account.invoice.line	v13 新增
stock.package	stock.quant.package	v19 新增（best-effort）

两种名称你都可以传入；resolver 会返回在目标实例中有效的那个。

字段变更

模型	字段	变更	边界
account.move.line	analytic_account_id → analytic_distribution	重命名	v16
product.template	uom_po_id	已移除（使用 uom_id）	v17（best-effort）
res.partner	company_type	已移除（使用 is_company）	v19（best-effort）

已移除的字段会连同一条 dropped_fields 警告从查询中被丢弃，而不会让整个调用失败。

能力

能力	可用性
api_key_auth	Odoo ≥ 14（更早版本需要密码）
jsonrpc_api_key	仅 Odoo ≤ 16；v17+ 在 /jsonrpc 上拒绝 API keys → 自动回退到 XML-RPC
update_field_translations	Odoo ≥ 16（更早版本使用带语言上下文的写入）

版本类型

Enterprise 专属的模型（启发式列表：documents.document、 sign.request、account.consolidation.period、quality.check、 helpdesk.ticket、planning.slot、appraisal.appraisal）在实例被检测为 Community 时会抛出 CompatError。运行时的模块探测是权威来源。

"best-effort" 边界

某些版本边界（上方已标注）是近似的，宜对照一个真实实例加以确认。由于该映射表是 由表驱动测试所覆盖的纯数据，修正一个边界只需一行编辑外加一行测试 （参见 贡献）。

实践中

始终针对 现代名称 编写代码。智能体无需知道版本：兼容层会为你解析。 如果一次查询返回了 dropped_fields，说明该字段在目标版本中不存在 ——请在上方表格中查找等价的现代名称。

Skill 参考：/odoo-tools:odoo-crossversion。