简介本资源是Odoo 17官方数据库结构的完整中文版数据字典专为Odoo开发者、实施顾问及进阶学习者设计解决英文文档阅读门槛高、模型字段含义不明确、二次开发时难以快速定位核心表与关联关系等实际问题。压缩包仅含1个PDF文件8.07MB内容由Navicat自动生成覆盖odoo数据库全量public模式下的200核心数据表如account_account、account_move_line、res_partner等并逐表标注字段名、类型、约束及业务含义目录层级清晰支持关键词检索与跳转。已有133人下载学习适合在定制开发、数据迁移、权限配置或调试SQL时作为权威参考手册随时查阅。字典中包含服务器连接信息、生成时间戳与版本标识确保技术时效性与环境可追溯性是理解Odoo底层数据建模逻辑不可或缺的实战型工具文档。1. Odoo 17 数据字典已翻译为中文不是数据库说明书而是你读懂业务系统的“中文词典”你有没有试过打开 Odoo 的后台数据库看到满屏的account_move_line、res_partner、stock_picking这类名字像在读一本用拉丁文写的财务报表明明界面里点的是「客户」、「销售单」、「库存调拨」一进数据库就变脸成一串冷冰冰的英文缩写——这不是技术门槛高是语言没对上。Odoo 17 数据字典已翻译为中文就是把这本“拉丁文词典”逐页翻成了你日常开会时说的中文account_move不再是“会计移动”而是「会计凭证」res_partner不再是“资源伙伴”而是「联系人含客户/供应商」stock_move不是“库存移动”而是「库存调拨明细」。它不教你写代码也不帮你装服务器但它能让你第一次打开 PostgreSQL 里的表结构时不用查谷歌、不翻源码、不问同事就能指着某一行说“哦这是销售订单的付款状态字段”。很多开发者踩过坑改错一个字段名导致报表取数全乱误删一张关联表整个采购流程卡死甚至因为看不懂account_analytic_line_stock_move_rel是干啥的硬生生绕开分析功能写了三套临时脚本。这份数据字典就是给这些时刻准备的“后悔药”——它不解决所有问题但能让你在动手前先听懂系统在说什么。2. 数据字典到底是什么不是代码注释也不是ER图而是一份“字段级普通话手册”2.1 它不是数据库设计文档而是运行时的“活字典”很多人第一反应是“不就是 Navicat 导出的表结构截图吗”错。Navicat 导出的只是字段名、类型、是否为空这些基础信息比如-- Navicat 只告诉你这个 Table: account_move Column: state Type: varchar(16) Nullable: NO Column: date Type: date Nullable: NO Column: journal_id Type: integer Nullable: YES但这份 Odoo 17 中文数据字典会进一步告诉你state字段中文含义为「凭证状态」取值范围为draft草稿、posted已过账、cancel已取消业务含义是控制凭证能否参与总账汇总、能否生成凭证号、能否被反审核前端对应「状态栏」下拉选项后端逻辑中常用于if move.state posted:判断。你看它把数据库字段和你在 Odoo 界面里看到的按钮、下拉框、报错提示、权限控制全部串起来了。它记录的是系统实际跑起来时每个字段扮演的角色而不是建表时工程师脑子里想的那个“理想模型”。2.2 它为什么必须是“中文”的因为 Odoo 的英文命名有三重陷阱Odoo 的英文字段名不是随意起的但恰恰因此更易误导初学者缩写陷阱acc不是 “account”而是accounting的简写inv在account_invoice_transaction_rel里指 “invoice”但在product_template_inv里可能指 “inventory”同一个缩写在不同模块语境下意思完全不同。抽象陷阱res开头的表如res_partner,res_users,res_company中的res是 “resource”资源但用户根本不会说“我新建了一个 resource”他们说的是“我新增了一个客户”或“我添加了一个员工”。用英文记等于强迫大脑多转一道翻译弯。历史包袱陷阱account_account表名直译是“账户账户”明显冗余。其实它是“会计科目主表”account在这里特指“会计科目”Chart of Accounts第二个account是为了区分于account_move凭证等其他 account 相关表。这种命名是 Odoo 早期为兼容性保留的但对学习者毫无友好度。中文数据字典直接跳过这些弯路用业务语言锚定字段本质。它不消灭英文名而是给你一句“人话翻译使用场景常见误用提醒”就像老司机在副驾给你念导航“前方300米右转——注意这里不是普通路口是带红绿灯的Y型岔口上次有人在这儿压线被拍了。”2.3 它怎么生成的为什么这份是 Odoo 17 专属不能套用 16 或 18这份字典基于真实 Odoo 17.0 社区版源码 PostgreSQL 实例导出关键在于三个“对得上”版本对得上Odoo 17 引入了account_payment_register_move_line_rel这类新关联表用于支付登记与凭证行的多对多关系而 Odoo 16 中同类逻辑还在account_payment表里用 JSON 字段硬塞。字典若照搬 16 版就会漏掉这张表或把字段解释成旧逻辑。模块对得上Odoo 是模块化架构。account_analytic_account_mrp_bom_rel这张表只在同时安装了account_analytic成本分析和mrp制造两个模块时才存在。字典里明确标注了“依赖模块account_analytic, mrp”避免你在一个精简部署的系统里死磕找不到这张表。工具链对得上它用 Navicat 生成原始结构但人工补全了 Odoo 特有的元信息——比如字段是否来自继承_inherit account.move、是否被api.depends装饰器标记为计算字段、是否在视图 XML 中被invisible1隐藏但数据库仍存在。这些信息 Navicat 看不见但开发调试时天天要查。所以它不是“自动翻译工具”而是由熟悉 Odoo 内部机制的人拿着 17 版源码、数据库、视图文件三件套一行一行核对出来的“人肉校准版”。3. 它和你见过的“数据库文档”“API文档”“模型文档”有什么区别3.1 和传统数据库ER图的区别不画关系线只讲“谁管谁”ER图喜欢画圆圈和连线标出account_move→account_move_line是一对多res_partner←→sale_order是多对多……看起来很美但实际开发中你很少需要知道“理论上它们能怎么连”你更常遇到的是“我在写一个销售订单确认后的自动开票逻辑该查sale_order的哪个字段去关联到account_move”“用户反馈‘客户余额’报表不准我该去res_partner表里看credit_limit还是去account_move_line里 sum 所有未核销行”中文数据字典不画虚线它直接告诉你sale_order表中字段account_move_ids类型为Many2many关联目标为account.move含义为「该销售订单生成的所有会计凭证」常用于order.account_move_ids.filtered(lambda m: m.state posted)获取已过账凭证。它把“关系”转化成可执行的代码片段和业务判断条件ER图告诉你“能连”它告诉你“该连哪条、为什么连这条、连错了会怎样”。3.2 和 Odoo 官方模型文档Model Reference的区别不讲抽象定义只讲落地字段Odoo 官网的 Model Reference 是权威的但它定位是“给插件开发者看的接口说明书”。比如对account.move模型它会写name: Char, requiredTrue, indexTrue, copyFalsestate: Selection, defaultdraft, requiredTruejournal_id: Many2one(account.journal)——全是技术契约没有业务灵魂。而中文数据字典会补充name字段中文名「凭证编号」规则为「日记账编码-年份-序号」如INV/2024/00012不可手动修改由journal_id和序列号规则自动生成若需自定义编号格式请修改对应日记账的「序列」配置而非直接 update 此字段。它把“字段定义”翻译成“你该怎么用、不该怎么用、改了会触发什么连锁反应”。官方文档告诉你“门锁是弹子锁”数据字典告诉你“钥匙插进去要顺时针拧两圈半逆时针拧会崩簧”。3.3 和 API 文档如 REST / JSON-RPC的区别不暴露接口只解释数据本体API 文档教你怎么调用/web/dataset/call_kw传什么参数返回什么 JSON 结构。但如果你拿到一个返回值{ id: 45, name: 客户A, parent_id: 22 }你依然不知道parent_id: 22是指向res_partner表的第22条记录还是res_company表的第22条这个name是客户全称还是简称是否包含地区前缀id是数据库主键还是业务唯一编码能否作为外部系统主键同步中文数据字典在res_partner表说明里直接写明parent_id: Many2one(res.partner)含义为「上级联系人可用于组织架构树」若为空则为顶层客户/供应商该字段允许自引用即 parent_id 可指向本表其他记录形成无限层级关系同步至外部系统时建议以id为主键但需注意其为数据库自增ID非业务编码。它不关心你用 HTTP 还是 XML-RPC 调它只确保你拿到任何一条数据时能立刻说出它每个字段的“身份、出身、职责”。4. 常见误区与易混概念别再把“数据字典”当成“SQL速查手册”4.1 误区一有了数据字典我就不用学 Odoo ORM 了为什么混看到字典里写着account_move_line.debit float就以为直接cr.execute(UPDATE account_move_line SET debit %s WHERE id %s, (new_val, line_id))就完事。怎么区分数据字典告诉你“字段是什么”ORM 告诉你“该怎么安全地改它”。debit字段受api.onchange、_compute、_inverse、访问权限、审计日志等多重约束。绕过 ORM 直接 SQL 更新可能触发account.move.line的balance自动重算失败绕过ir.rule权限检查让无权用户篡改数据不触发write()方法里的业务逻辑如库存联动、审批流推进。✅ 正确姿势用self.env[account.move.line].browse(line_id).write({debit: new_val})让 Odoo 自己走完整生命周期。4.2 误区二字典里写了字段中文名那我在视图 XML 里就可以用中文名当字段名为什么混字典里account_move.state对应「凭证状态」就以为视图里可以写field name凭证状态/。怎么区分XML 视图中的name属性永远是 Python 字段名英文不是中文标签。中文标签是通过string属性或ir.model.fields记录定义的!-- ✅ 正确name 是英文字段名 -- field namestate string凭证状态 widgetstatusbar/ !-- ❌ 错误name 不能写中文 -- field name凭证状态/数据字典的“中文名”是供你阅读理解用的不是语法标识符。它帮你建立映射但不替代语法规范。4.3 误区三所有表都在public模式下所以我查account_move就能拿到全部凭证为什么混Navicat 默认连public模式字典目录也写2.1.1.1. 模式: public就以为所有数据都在这儿。怎么区分Odoo 支持多数据库实例multi-database但同一数据库内不同模块可能创建自己的模式schema。例如public核心模块base, account, sale表hr人力资源模块专用模式含hr_employee表website网站模块模式含website_page表。而account_move确实在public但它的某些扩展字段如website_id可能来自website模块存储在public下但逻辑归属website。字典里每张表都标注了「所属模块」正是为了提醒你查数据前先看它归谁管别在public里大海捞针。4.4 误区四字典里列出了account_payment_method表那我直接往里 insert 一条记录就能新增支付方式为什么混看到表结构清晰name,code,payment_type就觉得增删改查和普通表一样。怎么区分account_payment_method是 Odoo 的配置型主数据Master Data它的生命周期由模块初始化、XML 数据加载、UI 表单共同管理。直接 SQL 插入不会触发create()方法中的默认值设置如activeTrue不会写入ir.model.data记录导致无法被ref(account.account_payment_method_manual_in)引用若code重复可能破坏account.journal对支付方式的绑定逻辑。✅ 正确姿势通过 UI「会计 配置 会计 支付方式」添加或用 XML 文件声明record idaccount_payment_method_manual_in modelaccount.payment.method field namename银行转账收款/field field namecodemanual/field field namepayment_typeinbound/field /record4.5 误区五字典里写了res_users.login是用户名那我导出所有login就能拿到全部账号清单为什么混login字段确实存用户名且res_users表可见就以为导出即得。怎么区分Odoo 的用户体系有三层隔离res.users用户主表含login,name,activeres_partner用户关联的联系人含email,phoneir_rule/res_groups权限组控制决定该用户能否看到res_users表本身。⚠️ 关键点普通用户非管理员默认无权读取res_users表。即使你用管理员账号导出login字段也仅用于认证真实业务中应优先使用partner_id关联的res_partner.email发送通知。字典里对res_users.login的说明会强调“仅用于系统登录认证业务联络请使用关联联系人的 email 字段”。提示数据字典的价值不在于让你“能做什么”而在于让你清醒地知道“为什么这么做会翻车以及正确的路在哪条”。它是一份防踩坑指南不是操作说明书。5. 什么时候该打开它什么时候该合上它——一份真实调试场景复盘5.1 场景客户要求增加「销售订单审批流」需在订单确认时自动创建待审凭证某公司上线 Odoo 17 后财务提出销售订单点击「确认」后不能立即生成会计凭证必须先经财务总监审批审批通过后再过账。开发接到需求第一反应是“改sale.order.confirm()方法”但卡在第一步订单确认后凭证是怎么生成的他打开数据字典搜索关键词「销售订单」快速定位到sale_order表往下翻到「关联字段」部分account_move_ids: Many2many(account.move), 含义为「该订单生成的全部会计凭证含草稿、已过账、已取消」invoice_ids: Many2many(account.move), 含义为「该订单关联的全部发票凭证仅 typeout_invoice」move_ids: One2many(stock.move, sale_line_id), 含义为「该订单行生成的库存调拨明细」。他意识到订单和凭证不是直连的中间隔着sale.order.line和account.move.line的映射。继续查sale_order_line表发现关键字段move_ids: One2many(stock.move, sale_line_id), 含义为「该订单行生成的库存调拨」invoice_lines: One2many(account.move.line, sale_line_ids), 含义为「该订单行对应的发票行」。再查account.move.line表看到sale_line_ids: Many2many(sale.order.line), 含义为「此凭证行所归属的销售订单行用于成本结转、收入确认」。线索串起来了Odoo 的标准逻辑是订单确认 → 生成库存调拨 → 调拨完成 → 生成发票 → 发票过账 → 凭证过账。但客户要的是“订单确认即生成草稿凭证等审批”。于是他不再硬改confirm()而是在sale.order上新增字段approval_state审批状态重写_action_confirm()调用原逻辑后主动调用self._create_invoices()生成草稿发票此时account_move_ids已有记录但statedraft添加审批按钮审批通过后遍历self.account_move_ids.filtered(lambda m: m.state draft)执行m.action_post()。整个过程他没碰一次 SQL没猜一个字段名全靠数据字典里对account_move_ids、invoice_ids、sale_line_ids的精准描述把模糊的“生成凭证”需求拆解成可落地的字段级操作。5.2 什么时候该合上它——三个明确的“停手信号”数据字典是强辅助不是万能钥匙。当你遇到以下情况请立刻合上它转向其他工具场景为什么该停手接下来该做什么你要查某条具体数据的值比如“客户A的余额是多少”字典告诉你res_partner.credit是「应收账款余额」但不告诉你当前值。它解释字段不提供数据快照。直接在 Odoo 界面「联系人 客户A 财务标签页」查看或用self.env[res.partner].browse(123).credit在 debug shell 中查。你正在写一个新模块需要定义新模型和字段字典只记录现有结构不指导你如何设计新表。它告诉你“别人怎么建的”不告诉你“你该怎么建”。查 Odoo 官方文档《Module Structure》和《Models》用models.Model继承按规范定义字段类型、关系、约束。你发现某个字段值异常比如account_move.state显示cancel但凭证还能编辑字典说明字段含义但不诊断数据一致性。它告诉你“cancel应该是不可编辑的”但不告诉你为什么这条数据坏了。启用 Odoo 的--log-leveldebug看write()调用栈检查是否有自定义模块覆盖了action_cancel()方法用psql查account_move表的__last_update和write_uid字段追溯修改源头。5.3 我的血泪经验从“查字典”到“建字典”的习惯转变刚接触 Odoo 时我把它当字典——遇到不懂的字段就翻。结果花了三天搞懂account_partial_reconcile表却在上线前夜发现自己写的对账脚本漏掉了max_date字段的过滤逻辑导致把三年前的已核销行又拉进来重算财务报表全乱。后来我养成了一个强制习惯每次打开数据字典前先问自己三个问题我要改的是「数据」还是「逻辑」改数据→查字段含义改逻辑→查方法名和调用链这个字段的值是由用户输入、系统计算、还是外部同步来的决定我该查表、查 compute 方法、还是查 import 脚本如果我改了它哪些下游字段或报表会跟着变数据字典里每张表末尾都有「影响范围」小节专门列关联视图、报表、工作流节点现在我不再只“用”字典而是把它当起点——查完account_move_line我会顺手打开account.move.line的 Python 源码看_compute_debit_credit()怎么算查完res_partner我会去base/views/res_partner_views.xml看字段在哪个视图层级被隐藏。数据字典给了我坐标而真正的路还得自己一步步走。希望帮到你。本文还有配套的精品资源点击获取