简介本资源是Odoo 17官方数据库结构的完整中文翻译版数据字典专为Odoo二次开发工程师、系统实施顾问及进阶学习者设计解决英文原版字典阅读门槛高、字段含义理解困难、模块间关联梳理不清等实际问题。压缩包内含1个PDF文件大小8.07MB内容基于Navicat自动生成覆盖PostgreSQL数据库中odoo库的public模式下全部核心表如account_account、account_account_tag等并按层级呈现引言、服务器配置、数据库结构、模式划分及详尽的表与字段说明目录结构严谨便于快速定位财务、销售、库存等关键模块的数据模型。已有133人下载学习读者可直接获取标准化的中文字段注释、表间关系映射及版本标注2024年8月生成显著提升定制开发、SQL查询编写与数据迁移效率。1. Odoo 17 数据字典中文版不是文档堆是开发调试的「数据库导航仪」你刚接手一个 Odoo 17 客户项目需求是改一个财务凭证导出逻辑——但account_move_line表里字段名全是英文缩写debit和credit倒好懂可balance,amount_currency,matched_debit_ids到底谁主谁从查官方文档翻源码还是硬着头皮试别折腾了。这份 Odoo 17 数据字典已翻译为中文就是专治这种「字段失语症」的实战工具它不是 PDF 手册而是用 Navicat 从真实 Odoo 17 PostgreSQL 数据库中结构化导出的完整元数据快照覆盖account_*,res_*,stock_*,mrp_*等全部核心模块共 500 张表每张表都标注了字段中文释义、数据类型、是否为空、主外键关系、索引信息甚至包含account_account_tag_account_move_line_rel这类多对多关联表的业务含义说明。适合三类人刚上手 Odoo 的实施顾问看懂客户数据在哪、二次开发工程师写 SQL 或 ORM 查询前先确认字段语义、系统集成开发者对接 ERP 时快速对齐字段映射。它不教你怎么装 Odoo但能让你在 3 分钟内定位到「客户付款单对应的数据库表是account_payment其状态字段叫state取值范围是draft,posted,cancelled」——这才是真实开发场景里最耗时间、又最不该靠猜的部分。2. 数据字典的本质与选型为什么 Navicat 导出比 ORM 模型更可靠2.1 数据字典不是「文档」而是数据库 Schema 的实时快照很多人误以为 Odoo 数据字典就是models.py里的字段定义汇总。错。models.py描述的是 Python 层的抽象逻辑比如fields.Many2one(res.partner)而实际存入 PostgreSQL 的是物理表结构字段名被自动转成小写下划线partner_id→partner_id关系字段会生成关联表res_partner_category_rel计算字段computed可能根本不落地存储。这份数据字典的价值正在于它绕过了 ORM 抽象层直接抓取数据库真实 Schema —— 用 Navicat 连接 Odoo 17 默认的 PostgreSQL 实例localhost:5432数据库名odoo执行SELECT * FROM pg_tables WHERE schemaname public获取所有表再逐表调用pg_columns查询字段元数据最后人工校对并翻译字段注释。这意味着你看到的account_move_line.debit字段其data_type是numeric(16,2)is_nullable为NOcolumn_default是0.00这些信息在account.move.line模型的 Python 定义里是找不到的。尤其当客户自定义了字段如x_customer_ref或启用了account_accountant等第三方模块Navicat 导出的数据字典能立刻暴露这些「隐藏字段」的存在和约束避免 ORM 查询时因字段不存在而报KeyError。2.2 为什么选 Navicat 而非 pgAdmin 或 SQL 命令行Navicat 在此场景有不可替代性它支持一键导出「带注释的完整 DDL 字段描述」为 HTML/PDF/Excel且能自动解析 PostgreSQL 的COMMENT ON COLUMN语句Odoo 源码中通过_sql_constraints或help参数生成的注释会落地到数据库。对比pg_dump --schema-only只输出建表语句不带字段说明psql -c \d table_name输出格式混乱无法批量导出而 pgAdmin 的「导出数据字典」功能默认不包含字段级中文注释需手动配置插件。Navicat 的优势在于其「结构化导出」能力它把pg_description系统表中的注释与information_schema.columns关联生成的 HTML 目录层级清晰如2.1.1.1.38. 表: account_move下直接展开字段列表且支持按表名/字段名全局搜索——这在排查「某个业务单据状态字段到底叫什么」时效率远超翻源码。我一般会先用 Navicat 连上测试库右键数据库 →「导出向导」→ 选择「结构」→ 勾选「包含注释」→ 输出为 HTML再用正则批量替换英文注释为中文如将Account move line替换为会计凭证行最后人工复核关键表如account_move,stock_picking的字段语义是否准确。这个流程确保了数据字典既反映真实数据库状态又具备中文可读性。2.3 中文翻译的边界哪些该译哪些必须保留英文翻译不是简单字对字。核心原则是业务概念译技术标识符不译。例如name字段在res_partner表中译为「名称」但在ir_model_fields表中必须保留name因为它是 Odoo 内部模型字段的唯一标识符ORM 查询时env[ir.model.fields].search([(name, , name)])依赖此值state字段统一译为「状态」但其枚举值draft,posted,cancel不翻译因为前端视图、Python 代码、SQL 查询都直接使用这些字符串外键字段如partner_id译为「客户/供应商 ID」而非「合作伙伴 ID」因为res.partner模块实际承载客户与供应商双重角色多对多关联表名account_account_tag_account_move_line_rel译为「会计科目标签与凭证行关联表」括号注明原名方便开发者查源码。提示所有翻译均基于 Odoo 17 官方中文语言包zh_CN术语校准如journal译为「日记账」而非「账簿」reconcile译为「对账」而非「核销」确保与界面显示一致。若你的项目启用的是zh_TW繁体中文需自行调整部分词汇。3. 如何用这份数据字典精准定位业务字段以「销售订单金额统计」为例3.1 从需求反推销售订单总金额存在哪张表假设需求是「统计所有已确认销售订单的总金额」。第一步不是写 SQL而是打开数据字典 HTML 文件用浏览器 CtrlF 搜索关键词搜sale→ 定位到sale_order表销售订单主表查其字段amount_total总金额、state状态、date_order下单日期注意amount_total的data_type是numeric(16,2)is_nullable为NO说明该字段必填且精度为两位小数再搜state→ 发现sale_order.state的取值范围在数据字典中明确列出draft,sent,sale,done,cancel其中sale表示已确认订单验证关联sale_order表的外键partner_id指向res_partner.idpricelist_id指向product_pricelist.id确认数据链路完整。3.2 构建安全 SQL利用数据字典规避常见陷阱有了字段信息写 SQL 就不再盲目。以下是一个生产环境可用的统计查询-- 统计已确认销售订单总金额含税 SELECT SUM(amount_total) AS total_amount, COUNT(*) AS order_count FROM sale_order WHERE state sale AND create_date 2024-01-01;逻辑说明state sale直接使用数据字典确认的枚举值避免用state IN (sale, done)错误包含已完成订单create_date字段在数据字典中标注为timestamp without time zone因此日期过滤用字符串2024-01-01即可PostgreSQL 自动转换无需TO_DATE()函数SUM()聚合函数作用于numeric类型字段结果精度保持两位小数符合财务要求。参数说明2024-01-01可替换为变量但必须确保格式为YYYY-MM-DD否则 PostgreSQL 会报错invalid input syntax for type timestamp。3.3 ORM 查询对照如何用env[sale.order]实现相同逻辑数据字典不仅用于 SQL更是 ORM 开发的校验基准。对应上述 SQLPython 代码应为# Odoo 17 中的标准 ORM 查询 orders env[sale.order].search([ (state, , sale), (create_date, , 2024-01-01) ]) total_amount sum(orders.mapped(amount_total)) # 注意mapped 返回 float 列表sum 后需 round(2) order_count len(orders)关键点验证数据字典确认sale_order.amount_total是numeric类型但 Odoo ORM 读取后转为 Pythonfloat可能导致精度丢失如100.01 200.02 300.03000000000003。因此生产代码中必须round(sum(...), 2)。而 SQL 的SUM(numeric)直接返回精确 numeric这是数据字典提醒你「何时该用 SQL何时该用 ORM」的典型场景。4. 避坑指南数据字典使用中 5 个血泪经验总结4.1 现象Navicat 导出的字段注释为空中文翻译无从下手原因Odoo 默认不为所有字段添加数据库级注释COMMENT ON COLUMN仅部分核心字段如res_partner.name有help属性生成的注释大量自定义字段或第三方模块字段注释缺失。解决先运行SELECT column_name, data_type, is_nullable FROM information_schema.columns WHERE table_name your_table;确认字段存在性再结合 Odoo 源码models.py中的help参数人工补全。例如account_move.line_ids字段在数据字典中无注释但查account/move.py可知其helpThe lines of the journal entry.译为「凭证行明细」。4.2 现象account_move_line表中debit和credit字段值全为 0原因Odoo 17 启用「多币种」或「公司货币」设置后debit/credit仅存储公司本位币金额而amount_currency存储原始币种金额若未设置currency_id则debit/credit为 0。解决数据字典中需特别标注account_move_line.debit的业务含义为「公司本位币借方金额」并提示查看account_move_line.currency_id和account_move_line.amount_currency字段组合使用。4.3 现象stock_picking表的state字段取值与界面显示不一致如界面显示「已发货」数据字典写done原因Odoo 界面状态显示由selection字段的selection参数定义但数据库存储的是键值done而界面翻译通过ir.translation表实现数据字典只反映数据库存储值不包含翻译层。解决在数据字典中为state字段增加「界面显示映射」备注例如stock_picking.state:draft→草稿, confirmed→待发货, assigned→已分配, done→已发货, cancel→已取消该映射需从models.py的selection定义中提取。4.4 现象res_users表中login字段长度为 64但实际插入超长邮箱时报错原因res_users.login字段在 PostgreSQL 中定义为varchar(64)但 Odoo 17 的res.users模型中增加了_constraints验证限制login必须是有效邮箱格式符号分隔且总长不超过 254 字符RFC 5321 标准但数据库层面未设CHECK约束。解决数据字典中需在res_users.login字段旁加注「应用层校验邮箱格式最大长度 254 字符」提醒开发者不能仅依赖数据库长度限制。4.5 现象account_account表的code字段在数据字典中显示varchar(64)但实际业务中会计科目编码最长仅 10 位原因code字段的数据库定义是通用的varchar(64)但具体长度由会计制度决定如中国小企业会计准则要求科目编码最多 10 位Odoo 本身不限制靠account.chart.template导入时的规则控制。解决在数据字典中为account_account.code添加业务约束说明「按中国会计制度一级科目编码 4 位二级 6 位三级 10 位实际长度由 chart template 决定非数据库强制」。5. 进阶技巧用数据字典生成自动化字段映射表对接 BI 工具5.1 场景痛点Power BI / Tableau 接入 Odoo 数据库时字段名全是英文业务人员看不懂BI 工具连接 PostgreSQL 后account_move_line.debit这样的字段名对财务人员毫无意义。手动重命名每个字段效率极低且易出错。解决方案是利用数据字典的结构化数据自动生成「字段映射 CSV」供 BI 工具批量导入。5.2 实操步骤从 HTML 数据字典提取字段信息并生成映射表首先将 Navicat 导出的 HTML 数据字典保存为odoo17_dict.html。使用 Python 解析 HTML 表格需安装beautifulsoup4from bs4 import BeautifulSoup import csv # 读取 HTML 文件 with open(odoo17_dict.html, r, encodingutf-8) as f: soup BeautifulSoup(f, html.parser) # 提取所有表格行每张表一个 table tables soup.find_all(table) mapping_rows [] for table in tables: # 获取表名通常在 caption 或第一个 th caption table.find(caption) if caption and 表: in caption.text: table_name caption.text.split(表:)[-1].strip() else: continue # 遍历字段行跳过表头 rows table.find_all(tr)[1:] # 第一行是表头 for row in rows: cols row.find_all([td, th]) if len(cols) 4: # 确保有字段名、类型、是否为空、注释列 field_name cols[0].get_text(stripTrue) data_type cols[1].get_text(stripTrue) is_nullable cols[2].get_text(stripTrue) comment cols[3].get_text(stripTrue) # 生成映射行数据库字段名, 中文名, 数据类型, 是否为空, 表名 mapping_rows.append([ f{table_name}.{field_name}, comment or field_name, # 注释为空时用字段名 data_type, 是 if YES in is_nullable else 否, table_name ]) # 写入 CSV with open(odoo17_field_mapping.csv, w, newline, encodingutf-8-sig) as f: writer csv.writer(f) writer.writerow([数据库字段, 中文名称, 数据类型, 是否可空, 所属表]) writer.writerows(mapping_rows) print(f生成映射表共 {len(mapping_rows)} 个字段)逻辑说明脚本遍历 HTML 中每个table对应一张数据库表提取字段名td第一列、数据类型第二列、是否为空第三列、中文注释第四列拼接为表名.字段名格式作为 BI 工具的原始字段名中文注释作为显示名称。encodingutf-8-sig确保 Excel 能正确识别中文。生成的 CSV 可直接在 Power BI 的「查询编辑器」中「高级编辑器」→Table.RenameColumns导入或 Tableau 的「数据源」→ 「字段别名」批量设置。5.3 映射表的实际应用财务报表字段速查表将生成的 CSV 导入 Excel按「所属表」筛选account_move得到关键财务字段映射数据库字段中文名称数据类型是否可空所属表account_move.name凭证编号varchar(20)否account_moveaccount_move.date凭证日期date否account_moveaccount_move.state状态varchar(16)否account_moveaccount_move.amount_total总金额numeric(16,2)否account_moveaccount_move.journal_id日记账integer否account_move这份速查表让财务人员无需接触数据库直接用「凭证编号」「凭证日期」「总金额」等中文字段名在 BI 工具中拖拽生成报表。更重要的是它暴露了潜在风险account_move.state是varchar(16)但实际只用draft,posted,cancel三个值若 BI 工具将其设为「文本」类型而非「分类」会导致排序错误cancel排在draft前。数据字典在此处的价值是提前预警数据类型与业务语义的错配。从那以后我每次给客户部署 BI 接口都强制走一遍这个 HTML → CSV → BI 字段映射流程哪怕只花 15 分钟也比后期被业务部门追着问「为什么凭证状态排序乱了」强十倍。希望帮到你。本文还有配套的精品资源点击获取
