用过用友U8的人十有八九都经历过这种尴尬领导问“上个月的回款数据从哪张表取”你只能打开数据库对着满屏的英文表名一张张翻。用友U8的后台表名一向以拼音缩写为主像 rdrecord、gl_accvouch、PO_Pomain 这种名字光靠猜很难一次猜中。而这类表名恰恰是日常报表开发、二次开发、数据迁移和问题排查时绕不开的核心。这篇文章就是我把多个U8账套里反复核对过的表名对照和经验整理成的一份实用手册涵盖基础档案、采购销售、库存存货、财务总账等核心模块同时附上我自己总结的命名规律和实战排查方法给正在跟U8数据库打交道的DBA、开发erp报表的工程师以及做数据维护的财务信息化同事做个参考。1. 为什么需要一张“表名中英文对照表”1.1 用友U8的数据库结构与命名规律用友U8通常运行在SQL Server环境一个数据库实例下面会挂多个账套库。账套库的命名有固定套路一般是 UFDATA_账套号_年度比如 UFDATA_001_2024 就代表001账套2024年度的数据。系统库 UFSystem 则保存所有账套的共用信息和操作员信息日常取业务数据基本都在UFDATA开头的账套库中操作。表名的命名规律其实比想象中好记大部分都来自业务术语的拼音首字母组合。比如 rdrecordrd是“入库/入单”相关的拼音缩写record本身就是英文“记录”合起来就是出入库单据主表。再比如 gl_accvouchgl对应总账general ledger的业务习惯accvouch是“凭证”的意思组合起来就是总账凭证表。只要抓住这个规律很多没见过的表名也能猜出个大概方向。但规律归规律真到了表结构层面光靠拼音猜还不够。同一张业务表在采购、销售、库存、财务模块之间的字段关联方式完全不同主表和子表的结构设计也各有差异。所以一份完整的对照表不仅要有“表名→中文名”的映射还要能说明每张表到底存什么、靠什么字段和其他表串起来。1.2 为什么直接看英文表名很痛苦U8的表名很少用完整的英文单词大多是拼音首字母的压缩形态比如 cCusCode客户编码、cVenCode供应商编码、cInvCode存货编码。这类命名在用了很多年之后问题会集中爆发新接手项目的人看 SELECT * FROM rdrecord 完全不知道这是出入库单时间一长同一张表在不同版本里字段有小调整旧注释失效跨模块开发时采购订单、销售订单、发货单分别对应不同表表与表之间没有统一文档全靠翻数据库字典。我在实际项目中吃过不少亏。有一次做采购订单和到货单的关联报表因为没弄清楚 PO_Pomain 和 PO_ArriveVouch 之间的关联字段联表出来的数量放大了一倍查了半天才发现是主表与子表关系搞错了。后来我把常用表整理成对照手册各种报表开发的效率才真正提上来。1.3 这些人最需要这份对照表ERP实施和运维工程师日常排查数据问题、做权限配置、核对业务流程都需要快速定位表。BI报表开发工程师写SQL取数、做数据仓库ETL、对接第三方报表工具表名对照是刚需。财务信息化人员对账、调账、期初余额核对经常需要查看凭证表和余额表的数据。学习用友数据库结构的学生做数据库课程设计或者ERP实验时对着对照表能少走很多弯路。2. 基础档案类表所有业务单据的“主数据底座”基础档案是U8所有业务的根基。采购单要挂供应商销售单要挂客户出入库要挂存货和仓库而这些业务单据指向的档案数据全部存放在基础档案表中。2.1 组织与人员档案表部门档案和职员档案是所有业务流转时最常关联的两个维度。部门编码和职员编码在采购、销售、报销、凭证中都会出现搞错关联字段会导致部门维度统计完全失真。表名中文含义关键字段说明Department部门档案cDepCode部门编码、cDepName部门名称、iDepGrade级次、bDepEnd是否末级Person职员档案cPersonCode职员编码、cPersonName职员姓名、cDepCode所属部门编码hr_hi_person人员信息扩展表部分版本中存人员其他属性视版本而异实操中我认为最关键的是部门表里的级次关系。U8的部门档案支持多级结构做汇总报表时如果只按部门名称分组会把上级部门的数据和下级部门的数据混在一起。正确做法是先判断 bDepEnd 是否为末级再决定是否需要向上汇总。职员的关联也要注意很多业务单据里存的不一定是Person表的主键而是职员编码 cPersonCode。联表时优先用 cPersonCode 关联避免直接使用自增ID因为不同账套里ID的起始值不一样直接以ID关联容易串数据。2.2 客商与存货仓库档案表客户、供应商、存货、仓库是进销存业务高频关联的四类主数据。在U8中客户和供应商是两套独立的档案编码体系即使同一个公司既是你客户又是你供应商在系统里也分别存在两个档案。表名中文含义关键字段说明Customer客户档案cCusCode客户编码、cCusName客户名称、cCCCode客户分类编码Vendor供应商档案cVenCode供应商编码、cVenName供应商名称、cCVCCode供应商分类编码Inventory存货档案cInvCode存货编码、cInvName存货名称、cInvStd规格型号、cInvCCode存货分类Warehouse仓库档案cWhCode仓库编码、cWhName仓库名称InventoryClass存货分类cInvCCode分类编码、cInvCName分类名称存货档案是U8中最复杂的基础档案之一。不仅是进销存单据会引用它财务的存货核算、成本计算也依赖存货档案中的计量单位、计价方式、默认税率等属性。查询存货数据时我建议把 InventoryClass 一起关联进来方便用存货分类做汇总。客户和供应商表里的分类字段也很有价值。做销售分析时经常需要按客户分类来判断大客户、普通客户、渠道客户的区别。如果只取客户名称分类粒度就丢了后期做分析还得回头补数据。2.3 会计科目与分类档案表会计科目表在U8里的表名很直接就是 Code。这张表是财务模块的核心主数据所有凭证分录中的科目编码、科目名称、余额方向、科目级次都记录在这里。表名中文含义关键字段说明Code会计科目表ccode科目编码、ccode_name科目名称、bprop余额方向、igrade科目级次CodeClass科目分类表部分版本使用用于科目分类管理Currency币种档案cCurCode币种编码、cCurName币种名称科目表的经典结构是ccode 是科目编码字段ccode_name 是科目名称。这里的 ccode 不是数字主键而是各位科目编码的字符串。比如“1002”代表银行存款“100201”代表银行存款下的某个明细科目。做财务分析时可以借用科目编码的字符串前缀做科目层级汇总例如 LEFT(ccode, 4) 可以归集到一级科目。我特别提醒一点Code 表在不同版本中可能命名不同有的版本直接叫 code有的版本在数据库字典里显示为 dbo.Code。但核心字段基本保持一致。财务对账时如果需要取科目余额方向直接在 bprop 字段上判断1代表借方0代表贷方不要自己去猜。3. 业务单据类表采购、销售、库存的流转链路业务单据是U8数据库中最复杂的部分因为每类单据都遵循“主表子表”的结构。主表存单据头信息比如单据编号、日期、往来单位子表存单据体明细比如存货编码、数量、单价、金额。主表和子表通过单据ID关联这是理解U8业务表的重中之重。3.1 采购模块核心表采购业务的链路大致是请购单 → 采购订单 → 到货单 → 采购入库单 → 采购发票。每个环节都有对应的主表和子表数据从上游单据复制到下游单据时还会保留来源单据的关联信息。表名中文含义关键字段说明PO_Pomain采购订单主表cPOID订单主键、cSOCode订单号、dPODate订单日期、cVenCode供应商编码PO_Podetails采购订单子表iPOID关联主表cPOID、cInvCode存货编码、iQuantity数量、iPrice单价PO_ArriveVouch采购到货单主表到货单号、到货日期、供应商PO_ArriveVouchs采购到货单子表关联到货单主表存货、数量PurchaseBillVouch采购发票主表发票号、供应商、开票日期PurchaseBillVouchs采购发票子表关联发票主表存货、数量、金额采购订单的取数逻辑相对简单主表关联供应商子表关联存货。需要特别注意的是 PO_Pomain 中的 cSOCode 字段它代表采购订单号有些人会误以为这是销售订单号其实在U8的采购模块里cSOCode 就是采购订单的单据号命名上的“SO”容易引起混淆实际业务含义完全不是销售订单。做采购分析报表时我建议把 PO_Pomain、PO_Podetails、Vendor、Inventory 四张表关联起来形成“订单号供应商存货数量金额”的宽表。如果做采购执行分析还需要和到货单、入库单做进一步关联此时要注意去重因为一张采购订单可能分批到货、分批入库关联粒度如果不细化到子表数据交叉相乘会导致数量翻倍。3.2 销售模块核心表销售模块的表结构与采购模块高度类似主表加子表的形式贯穿始终。销售业务的核心链路是销售订单 → 发货单 → 销售出库单 → 销售发票。表名中文含义关键字段说明SO_SOMain销售订单主表cSOCode销售订单号、dSODate订单日期、cCusCode客户编码SO_SODetails销售订单子表iSOID关联主表、cInvCode存货编码、iQuantity数量、iPrice无税单价DispatchList发货单主表cDLCode发货单号、发货日期、客户编码DispatchLists发货单子表存货、数量、发货仓库SaleBillVouch销售发票主表发票号、客户、开票日期SaleBillVouchs销售发票子表存货、数量、价税合计销售订单表 SO_SOMain 中的 iQuantity 和 iPrice 字段我见过的很多新手会忽略税率字段直接做数量和单价的乘积来算金额结果和系统里对不上。实际上U8的销售订单金额包含无税金额、税额、价税合计三个概念分散在子表的不同字段中。取数前先确认要的是含税还是无税口径再去对应字段。发货单表和销售发票表是销售出库和收入确认的关键。做收入确认报表时优先从 SaleBillVouch 和 SaleBillVouchs 取数据因为发票代表已经确认的收入。如果要分析订单转化率则要依次关联 SO_SOMain → DispatchList → SaleBillVouch通过单据编号逐层下钻这一步容易乱建议先在小范围内验证关联行数的正确性。3.3 库存与存货模块核心表库存模块的经典设计是使用 rdrecord 和 rdrecords 两张表统管所有出入库单据。这里的“rd”就是入/出ru/chu的拼音缩写record则代表记录。采购入库、销售出库、调拨出入库、盘盈盘亏等所有库存变动都会写入这两张表。表名中文含义关键字段说明rdrecord出入库单据主表ID主键、cVouchCode单据号、dDate单据日期、cWhCode仓库、bRdFlag收发标志rdrecords出入库单据子表rdid关联主表ID、cInvCode存货、iQuantity数量、iUnitCost成本CurrentStock现存量表cWhCode仓库、cInvCode存货、iQuantity结存数量IA_Subsidiary存货核算明细账存货核算模块的明细记录表字段因版本而异rdrecord 里的 bRdFlag 是收发标志字段0代表入库1代表出库这个字段决定了单据的业务方向。很多报表开发人员在做库存流水分析时会忘记加这个条件导致出入库方向全部混乱。另外 rdrecords 里的 iUnitCost 是成本字段做存货成本分析时通常会从这里取数但要注意计价方式会影响成本金额的计算逻辑并非所有版本都直接存最终成本。CurrentStock 是现存量表但这份表的数据是库存模块根据出入库流水实时汇总出来的不是直接手动维护。很多实施顾问在核对库存时会拿 CurrentStock 和 rdrecord 做对比这个思路没问题但要保证系统没有未审核单据否则流水表和现存量表之间会有差异。4. 财务总账与凭证核心表报表开发绕不开的几张大表财务模块是U8数据库中使用频率最高的一部分无论是给财务部做管理报表还是做外部审计的数据准备都离不开总账相关表。财务表的命名习惯和业务模块有所不同更多使用 gl 前缀。4.1 凭证表gl_accvouch总账凭证表在U8中的表名是 gl_accvouch这是整个财务模块数据量最大、使用频率最高的表。它的结构和业务主表子表模式有一点差别凭证主表和凭证分录信息都存在一个表里每一条分录就是一行记录。表名中文含义关键字段说明gl_accvouch凭证表i_id分录ID、iperiod期间、csign凭证字、ino_id凭证号、ccode科目编码、md借方金额、mc贷方金额、cdigest摘要gl_accvouchdetail凭证辅助核算表i_id关联凭证分录ID、cItemCode辅助核算项、cItemClass辅助核算大类gl_balance科目余额表ccode科目编码、iperiod期间、mb期初余额、md借方发生、mc贷方发生、me期末余额凭证表 gl_accvouch 的关联关系并不复杂难点在于理解字段含义。md 是借方金额mc 是贷方金额这两个字段都是浮点型取数时要注意金额精度。i_id 是每笔分录的唯一标识不是凭证的唯一标识同一张凭证包含多笔分录所以会有多条 i_id 记录凭证号 ino_id 和凭证字 csign 才能唯一标识一张凭证。辅助核算信息存放在 gl_accvouchdetail 中像部门、客户、供应商、项目、个人等辅助核算项都在这里。做部门费用分析时如果只是从 gl_accvouch 取数会发现没有部门信息必须关联 gl_accvouchdetail 才能拿到部门辅助核算的数据。4.2 余额与期初相关表科目余额表 gl_balance 是财务分析时的高频表。这张表直接提供每个会计期间各科目的期初余额、借方发生额、贷方发生额和期末余额是资产负债表和利润表取数的基础。它的期间字段 iperiod 从0到120通常表示年初或建账期初1到12分别对应每个会计期间。表名中文含义关键字段说明gl_balance科目余额表ccode科目、iperiod期间、mb期初、md借方累计、mc贷方累计、me期末gl_kmxx科目信息辅助表部分版本使用存放科目其他属性gl_mend月末结账表记录各期间结账状态我在做利润表模板时习惯直接从 gl_balance 中按科目编码筛选收入类和费用类科目再按期间汇总发生额。不过这里有个细节gl_balance 中的发生额是累计发生还是本期发生不同版本字段含义略有区别。实操前最好先用单张凭证做一次手工验证确认字段口径后再大批量取数。结账状态表 gl_mend 适合用来判断某个月份是否已经完成结账。做财务数据快照或者关账检查时先查这张表可以避免取到未结账期间的波动数据对审计场景非常有用。4.3 财务模块的扩展表结构除了总账核心表U8财务模块还包含应收应付、固定资产、工资等子模块它们各自有一组以模块缩写开头的表。应收表通常以 ar 开头应付表以 ap 开头固定资产表以 fa 开头工资表以 wa 开头。表名中文含义关键字段说明ar_detail应收明细账记录应收单、收款单等明细ap_detail应付明细账记录应付单、付款单等明细fa_cards固定资产卡片固定资产卡片主表wa_gzdata工资数据表工资项目数据应收应付、固定资产这些模块的表名和字段在不同版本之间变化比较大我一般建议按“模块前缀业务动作”的方式来记忆真正开发时再通过数据库自带的中文注释或字典工具确认具体字段。5. 手把手实操用SQL Server快速“摸”清表结构5.1 打开账套库的表清单用友U8的数据存放在SQL Server中打开 SQL Server Management Studio连接到U8对应的数据库实例展开“数据库”节点找到 UFDATA_001_2024 这样的账套库点击“表”节点就能看到成百上千张表。如果表数量太多眼睛看不过来可以用SQL语句直接搜索。SELECT t.name AS 表名, ep.value AS 表说明 FROM sys.tables t LEFT JOIN sys.extended_properties ep ON ep.major_id t.object_id AND ep.minor_id 0 WHERE t.name LIKE %PO% ORDER BY t.name;这段脚本的作用是找出所有表名中包含 PO 的表同时把表的中文说明也带出来。用友U8在创建数据库时大部分表都写了扩展属性作为中文注释所以查看扩展属性比盲猜表名靠谱很多。查询字段信息也类似用系统视图可以一次性把字段名、数据类型、中文说明全部拿出来。SELECT c.name AS 字段名, t.name AS 数据类型, ep.value AS 字段说明 FROM sys.columns c JOIN sys.types t ON c.user_type_id t.user_type_id LEFT JOIN sys.extended_properties ep ON ep.major_id c.object_id AND ep.minor_id c.column_id WHERE c.object_id OBJECT_ID(rdrecord) ORDER BY c.column_id;运行这段SQLrdrecord 表的所有字段、类型和中文注释就一目了然了。我最开始整理对照表时就是用这种方法把常用表的字段说明批量导出来再结合业务场景按模块归档效率比一个一个表翻高很多。5.2 主表和子表的关联关系怎么判断U8的业务表几乎都是“主表子表”的组合主表存单据头子表存单据体关联字段通常有两种常见命名方式。第一种是子表直接用一个“主表名ID”的字段关联主表比如 PO_Podetails 表中的 iPOID 就对应 PO_Pomain 表中的 cPOID。第二种是使用简化的关联字段比如 rdrecords 表中的 rdid 对应 rdrecord 表中的 ID。判断主表和子表关系最靠谱的方法是先看主键和外键约束。SQL Server 的 sys.foreign_keys 视图会展示表之间的外键关系如果表设计时创建了外键直接查询就能看到完整的关联链路。SELECT fk.name AS 外键名, tp.name AS 主表, ref.name AS 子表 FROM sys.foreign_keys fk JOIN sys.tables tp ON fk.referenced_object_id tp.object_id JOIN sys.tables ref ON fk.parent_object_id ref.object_id WHERE tp.name PO_Pomain ORDER BY fk.name;但在实际账套中不一定所有表都建了外键很多时候只有索引而没有外键约束。这种情况下就得靠字段命名的规律来推断主表的ID字段通常是单据主键子表中带同样业务含义的字段就是关联外键。我自己的判断顺序是先看字段名再看索引最后看数据内容。5.3 快速生成属于你自己的“业务级字典”依赖官方文档或者网上现成的表名对照始终不如自己动手整理一份适合当前项目的字典。我的做法分三步第一步写脚本导出所有表的字段和说明保存成Excel底稿。第二步按业务模块对表进行分类采购类、销售类、库存类、财务类、基础档案类各建一个Sheet把核心表放在前面。第三步每整理一张表就随手写一条验证SQL比如 SELECT TOP 100 * FROM 表名确认这张表实际存储的数据和表名含义一致。Excel底稿里我还会加一列“常用关联表”把经常一起联表查询的表名记录下来。比如销售订单主表 SO_SOMain 的常用关联表是客户档案 Customer、存货档案 Inventory、发货单主表 DispatchList。这样后续开发新报表时直接翻底稿就能找到该关联的路径。这个过程不需要一次性做完平时开发报表时遇到一张新表就补充一次坚持几个月后你会拥有一份比厂商标准文档还要贴合自己项目的表结构字典。6. 常见问题排查与避坑实录6.1 表名搜不到怎么办有次在客户环境里做二次开发我按习惯写 SELECT * FROM PO_Pomain结果SQL Server报“对象名无效”。当时第一反应是表不存在后来排查发现系统安装的是U8的轻量化版本采购订单表名被改成了 PU_ 前缀。U8不同版本、不同产品线之间的表名确实存在差异遇到搜不到的情况先不要怀疑自己记错了优先用模糊查询在系统库中搜索。SELECT t.name AS 表名, ep.value AS 表说明 FROM sys.tables t LEFT JOIN sys.extended_properties ep ON ep.major_id t.object_id AND ep.minor_id 0 WHERE t.name LIKE %Order% OR t.name LIKE %Pomain% OR t.name LIKE %PO% ORDER BY t.name;搜索时多换几个关键词中文拼音首字母、英文单词、模块缩写都可以试一遍。另外也要确认当前选中的数据库是否正确很多“表名无效”的报错其实是因为连接到了 master 库或者另一个账套库。6.2 联表查询数据翻倍做报表时最常见的问题就是联表后数据突然变多。我在处理采购订单和入库单的关联时遇到过这种情况。根本原因是一张主表对应多张子表如果同时关联两张子表数据行数就会成倍放大。举个具体例子PO_Pomain 是采购订单主表PO_Podetails 是采购订单子表假设一张订单有3行明细。如果要把采购订单和到货单关联而到货单子表有2行数据那么直接联表后这张订单会变成6行。解决方法是先分别做订单明细汇总和到货明细汇总再在汇总结果上进行关联避免底层单据明细发生笛卡尔积。我整理了一个报表取数原则明细对明细关联时先从业务上确认关联层级一致不一致时先做子查询聚合再关联主表。这条原则在U8所有模块的报表开发中都适用。6.3 大小写、编码和备份恢复问题SQL Server默认对表名不区分大小写所以 PO_Pomain 和 po_pomain 在SQL Server里是一样的。但如果你把数据导出到MySQL这类对大小写敏感的环境中就要特别注意表名的大小写保持一致。MySQL 8.4 的表名大小写问题尤其容易踩坑导出时最好统一为小写避免后续维护时的混乱。编码方面U8的数据库通常使用中文排序规则比如 Chinese_PRC_CI_AS。从外部导入数据时如果目标表字段类型是 varchar 而数据里有生僻字或特殊符号容易出现乱码。遇到这种情况优先检查排序规则是否一致或者把字段类型改成 nvarchar 再导入。备份恢复的坑更隐蔽。恢复U8账套备份后如果只恢复了账套库而没有同步更新UFSystem系统库中的账套信息U8客户端会提示账套不存在。正常流程是恢复账套库后在系统管理里执行“升级SQL Server数据库”操作让系统库和账套库的版本信息重新对齐。这一点对经常做环境迁移的同学尤其重要。6.4 金额对不上先查币种和汇率财务对账时经常发现系统里的金额和数据库查出来的金额差很多很多情况下不是取数逻辑错了而是币种和汇率字段没有处理。U8的业务单据同时支持多币种核算单据上的金额可能是原币金额也可能是本币金额。查询销售发票时需要同时关注币种字段和汇率字段。如果只看原币金额不做本币折算汇总出来的数据和财务账面的本位币金额必然对不上。遇到金额差异先看表里有没有币种字段 cCurCode再看有没有汇率字段 iExchRate然后确认当前统计口径是本位币还是原币。6.5 单据类型字段的隐藏逻辑库存模块的 rdrecord 表里单据类型字段 cVouchType 或类似字段决定了这条记录属于采购入库、销售出库、调拨出入库还是其他类型。直接对这个字段做过滤可以快速实现按单据类型统计。但单据类型在U8不同版本中维护方式不同有的是编码01代表采购入库、02代表销售出库有的是以具体单据名称存储。踩过坑之后我建议写SQL时先对单据类型字段做一次 GROUP BY看看当前版本里到底有哪些取值再写WHERE条件不要拿着旧版本的编码逻辑直接套用。我个人在实际操作中最深的一点体会是表名对照表不是整理一次就完事的东西而是需要跟着项目版本和业务范围持续更新的活文档。每做完一个报表、每排查完一个数据问题把新碰到的表名、字段和关联关系补充进去这本手册才会越用越顺手。后续如果你手头正好有U8环境我建议你花一个下午跑一遍文中提到的几条查询SQL把当前版本的常用表结构导出来亲手整理一遍比看十篇文档都管用。
用友U8数据库表名中英文对照手册：核心表结构解析
用过用友U8的人十有八九都经历过这种尴尬领导问“上个月的回款数据从哪张表取”你只能打开数据库对着满屏的英文表名一张张翻。用友U8的后台表名一向以拼音缩写为主像 rdrecord、gl_accvouch、PO_Pomain 这种名字光靠猜很难一次猜中。而这类表名恰恰是日常报表开发、二次开发、数据迁移和问题排查时绕不开的核心。这篇文章就是我把多个U8账套里反复核对过的表名对照和经验整理成的一份实用手册涵盖基础档案、采购销售、库存存货、财务总账等核心模块同时附上我自己总结的命名规律和实战排查方法给正在跟U8数据库打交道的DBA、开发erp报表的工程师以及做数据维护的财务信息化同事做个参考。1. 为什么需要一张“表名中英文对照表”1.1 用友U8的数据库结构与命名规律用友U8通常运行在SQL Server环境一个数据库实例下面会挂多个账套库。账套库的命名有固定套路一般是 UFDATA_账套号_年度比如 UFDATA_001_2024 就代表001账套2024年度的数据。系统库 UFSystem 则保存所有账套的共用信息和操作员信息日常取业务数据基本都在UFDATA开头的账套库中操作。表名的命名规律其实比想象中好记大部分都来自业务术语的拼音首字母组合。比如 rdrecordrd是“入库/入单”相关的拼音缩写record本身就是英文“记录”合起来就是出入库单据主表。再比如 gl_accvouchgl对应总账general ledger的业务习惯accvouch是“凭证”的意思组合起来就是总账凭证表。只要抓住这个规律很多没见过的表名也能猜出个大概方向。但规律归规律真到了表结构层面光靠拼音猜还不够。同一张业务表在采购、销售、库存、财务模块之间的字段关联方式完全不同主表和子表的结构设计也各有差异。所以一份完整的对照表不仅要有“表名→中文名”的映射还要能说明每张表到底存什么、靠什么字段和其他表串起来。1.2 为什么直接看英文表名很痛苦U8的表名很少用完整的英文单词大多是拼音首字母的压缩形态比如 cCusCode客户编码、cVenCode供应商编码、cInvCode存货编码。这类命名在用了很多年之后问题会集中爆发新接手项目的人看 SELECT * FROM rdrecord 完全不知道这是出入库单时间一长同一张表在不同版本里字段有小调整旧注释失效跨模块开发时采购订单、销售订单、发货单分别对应不同表表与表之间没有统一文档全靠翻数据库字典。我在实际项目中吃过不少亏。有一次做采购订单和到货单的关联报表因为没弄清楚 PO_Pomain 和 PO_ArriveVouch 之间的关联字段联表出来的数量放大了一倍查了半天才发现是主表与子表关系搞错了。后来我把常用表整理成对照手册各种报表开发的效率才真正提上来。1.3 这些人最需要这份对照表ERP实施和运维工程师日常排查数据问题、做权限配置、核对业务流程都需要快速定位表。BI报表开发工程师写SQL取数、做数据仓库ETL、对接第三方报表工具表名对照是刚需。财务信息化人员对账、调账、期初余额核对经常需要查看凭证表和余额表的数据。学习用友数据库结构的学生做数据库课程设计或者ERP实验时对着对照表能少走很多弯路。2. 基础档案类表所有业务单据的“主数据底座”基础档案是U8所有业务的根基。采购单要挂供应商销售单要挂客户出入库要挂存货和仓库而这些业务单据指向的档案数据全部存放在基础档案表中。2.1 组织与人员档案表部门档案和职员档案是所有业务流转时最常关联的两个维度。部门编码和职员编码在采购、销售、报销、凭证中都会出现搞错关联字段会导致部门维度统计完全失真。表名中文含义关键字段说明Department部门档案cDepCode部门编码、cDepName部门名称、iDepGrade级次、bDepEnd是否末级Person职员档案cPersonCode职员编码、cPersonName职员姓名、cDepCode所属部门编码hr_hi_person人员信息扩展表部分版本中存人员其他属性视版本而异实操中我认为最关键的是部门表里的级次关系。U8的部门档案支持多级结构做汇总报表时如果只按部门名称分组会把上级部门的数据和下级部门的数据混在一起。正确做法是先判断 bDepEnd 是否为末级再决定是否需要向上汇总。职员的关联也要注意很多业务单据里存的不一定是Person表的主键而是职员编码 cPersonCode。联表时优先用 cPersonCode 关联避免直接使用自增ID因为不同账套里ID的起始值不一样直接以ID关联容易串数据。2.2 客商与存货仓库档案表客户、供应商、存货、仓库是进销存业务高频关联的四类主数据。在U8中客户和供应商是两套独立的档案编码体系即使同一个公司既是你客户又是你供应商在系统里也分别存在两个档案。表名中文含义关键字段说明Customer客户档案cCusCode客户编码、cCusName客户名称、cCCCode客户分类编码Vendor供应商档案cVenCode供应商编码、cVenName供应商名称、cCVCCode供应商分类编码Inventory存货档案cInvCode存货编码、cInvName存货名称、cInvStd规格型号、cInvCCode存货分类Warehouse仓库档案cWhCode仓库编码、cWhName仓库名称InventoryClass存货分类cInvCCode分类编码、cInvCName分类名称存货档案是U8中最复杂的基础档案之一。不仅是进销存单据会引用它财务的存货核算、成本计算也依赖存货档案中的计量单位、计价方式、默认税率等属性。查询存货数据时我建议把 InventoryClass 一起关联进来方便用存货分类做汇总。客户和供应商表里的分类字段也很有价值。做销售分析时经常需要按客户分类来判断大客户、普通客户、渠道客户的区别。如果只取客户名称分类粒度就丢了后期做分析还得回头补数据。2.3 会计科目与分类档案表会计科目表在U8里的表名很直接就是 Code。这张表是财务模块的核心主数据所有凭证分录中的科目编码、科目名称、余额方向、科目级次都记录在这里。表名中文含义关键字段说明Code会计科目表ccode科目编码、ccode_name科目名称、bprop余额方向、igrade科目级次CodeClass科目分类表部分版本使用用于科目分类管理Currency币种档案cCurCode币种编码、cCurName币种名称科目表的经典结构是ccode 是科目编码字段ccode_name 是科目名称。这里的 ccode 不是数字主键而是各位科目编码的字符串。比如“1002”代表银行存款“100201”代表银行存款下的某个明细科目。做财务分析时可以借用科目编码的字符串前缀做科目层级汇总例如 LEFT(ccode, 4) 可以归集到一级科目。我特别提醒一点Code 表在不同版本中可能命名不同有的版本直接叫 code有的版本在数据库字典里显示为 dbo.Code。但核心字段基本保持一致。财务对账时如果需要取科目余额方向直接在 bprop 字段上判断1代表借方0代表贷方不要自己去猜。3. 业务单据类表采购、销售、库存的流转链路业务单据是U8数据库中最复杂的部分因为每类单据都遵循“主表子表”的结构。主表存单据头信息比如单据编号、日期、往来单位子表存单据体明细比如存货编码、数量、单价、金额。主表和子表通过单据ID关联这是理解U8业务表的重中之重。3.1 采购模块核心表采购业务的链路大致是请购单 → 采购订单 → 到货单 → 采购入库单 → 采购发票。每个环节都有对应的主表和子表数据从上游单据复制到下游单据时还会保留来源单据的关联信息。表名中文含义关键字段说明PO_Pomain采购订单主表cPOID订单主键、cSOCode订单号、dPODate订单日期、cVenCode供应商编码PO_Podetails采购订单子表iPOID关联主表cPOID、cInvCode存货编码、iQuantity数量、iPrice单价PO_ArriveVouch采购到货单主表到货单号、到货日期、供应商PO_ArriveVouchs采购到货单子表关联到货单主表存货、数量PurchaseBillVouch采购发票主表发票号、供应商、开票日期PurchaseBillVouchs采购发票子表关联发票主表存货、数量、金额采购订单的取数逻辑相对简单主表关联供应商子表关联存货。需要特别注意的是 PO_Pomain 中的 cSOCode 字段它代表采购订单号有些人会误以为这是销售订单号其实在U8的采购模块里cSOCode 就是采购订单的单据号命名上的“SO”容易引起混淆实际业务含义完全不是销售订单。做采购分析报表时我建议把 PO_Pomain、PO_Podetails、Vendor、Inventory 四张表关联起来形成“订单号供应商存货数量金额”的宽表。如果做采购执行分析还需要和到货单、入库单做进一步关联此时要注意去重因为一张采购订单可能分批到货、分批入库关联粒度如果不细化到子表数据交叉相乘会导致数量翻倍。3.2 销售模块核心表销售模块的表结构与采购模块高度类似主表加子表的形式贯穿始终。销售业务的核心链路是销售订单 → 发货单 → 销售出库单 → 销售发票。表名中文含义关键字段说明SO_SOMain销售订单主表cSOCode销售订单号、dSODate订单日期、cCusCode客户编码SO_SODetails销售订单子表iSOID关联主表、cInvCode存货编码、iQuantity数量、iPrice无税单价DispatchList发货单主表cDLCode发货单号、发货日期、客户编码DispatchLists发货单子表存货、数量、发货仓库SaleBillVouch销售发票主表发票号、客户、开票日期SaleBillVouchs销售发票子表存货、数量、价税合计销售订单表 SO_SOMain 中的 iQuantity 和 iPrice 字段我见过的很多新手会忽略税率字段直接做数量和单价的乘积来算金额结果和系统里对不上。实际上U8的销售订单金额包含无税金额、税额、价税合计三个概念分散在子表的不同字段中。取数前先确认要的是含税还是无税口径再去对应字段。发货单表和销售发票表是销售出库和收入确认的关键。做收入确认报表时优先从 SaleBillVouch 和 SaleBillVouchs 取数据因为发票代表已经确认的收入。如果要分析订单转化率则要依次关联 SO_SOMain → DispatchList → SaleBillVouch通过单据编号逐层下钻这一步容易乱建议先在小范围内验证关联行数的正确性。3.3 库存与存货模块核心表库存模块的经典设计是使用 rdrecord 和 rdrecords 两张表统管所有出入库单据。这里的“rd”就是入/出ru/chu的拼音缩写record则代表记录。采购入库、销售出库、调拨出入库、盘盈盘亏等所有库存变动都会写入这两张表。表名中文含义关键字段说明rdrecord出入库单据主表ID主键、cVouchCode单据号、dDate单据日期、cWhCode仓库、bRdFlag收发标志rdrecords出入库单据子表rdid关联主表ID、cInvCode存货、iQuantity数量、iUnitCost成本CurrentStock现存量表cWhCode仓库、cInvCode存货、iQuantity结存数量IA_Subsidiary存货核算明细账存货核算模块的明细记录表字段因版本而异rdrecord 里的 bRdFlag 是收发标志字段0代表入库1代表出库这个字段决定了单据的业务方向。很多报表开发人员在做库存流水分析时会忘记加这个条件导致出入库方向全部混乱。另外 rdrecords 里的 iUnitCost 是成本字段做存货成本分析时通常会从这里取数但要注意计价方式会影响成本金额的计算逻辑并非所有版本都直接存最终成本。CurrentStock 是现存量表但这份表的数据是库存模块根据出入库流水实时汇总出来的不是直接手动维护。很多实施顾问在核对库存时会拿 CurrentStock 和 rdrecord 做对比这个思路没问题但要保证系统没有未审核单据否则流水表和现存量表之间会有差异。4. 财务总账与凭证核心表报表开发绕不开的几张大表财务模块是U8数据库中使用频率最高的一部分无论是给财务部做管理报表还是做外部审计的数据准备都离不开总账相关表。财务表的命名习惯和业务模块有所不同更多使用 gl 前缀。4.1 凭证表gl_accvouch总账凭证表在U8中的表名是 gl_accvouch这是整个财务模块数据量最大、使用频率最高的表。它的结构和业务主表子表模式有一点差别凭证主表和凭证分录信息都存在一个表里每一条分录就是一行记录。表名中文含义关键字段说明gl_accvouch凭证表i_id分录ID、iperiod期间、csign凭证字、ino_id凭证号、ccode科目编码、md借方金额、mc贷方金额、cdigest摘要gl_accvouchdetail凭证辅助核算表i_id关联凭证分录ID、cItemCode辅助核算项、cItemClass辅助核算大类gl_balance科目余额表ccode科目编码、iperiod期间、mb期初余额、md借方发生、mc贷方发生、me期末余额凭证表 gl_accvouch 的关联关系并不复杂难点在于理解字段含义。md 是借方金额mc 是贷方金额这两个字段都是浮点型取数时要注意金额精度。i_id 是每笔分录的唯一标识不是凭证的唯一标识同一张凭证包含多笔分录所以会有多条 i_id 记录凭证号 ino_id 和凭证字 csign 才能唯一标识一张凭证。辅助核算信息存放在 gl_accvouchdetail 中像部门、客户、供应商、项目、个人等辅助核算项都在这里。做部门费用分析时如果只是从 gl_accvouch 取数会发现没有部门信息必须关联 gl_accvouchdetail 才能拿到部门辅助核算的数据。4.2 余额与期初相关表科目余额表 gl_balance 是财务分析时的高频表。这张表直接提供每个会计期间各科目的期初余额、借方发生额、贷方发生额和期末余额是资产负债表和利润表取数的基础。它的期间字段 iperiod 从0到120通常表示年初或建账期初1到12分别对应每个会计期间。表名中文含义关键字段说明gl_balance科目余额表ccode科目、iperiod期间、mb期初、md借方累计、mc贷方累计、me期末gl_kmxx科目信息辅助表部分版本使用存放科目其他属性gl_mend月末结账表记录各期间结账状态我在做利润表模板时习惯直接从 gl_balance 中按科目编码筛选收入类和费用类科目再按期间汇总发生额。不过这里有个细节gl_balance 中的发生额是累计发生还是本期发生不同版本字段含义略有区别。实操前最好先用单张凭证做一次手工验证确认字段口径后再大批量取数。结账状态表 gl_mend 适合用来判断某个月份是否已经完成结账。做财务数据快照或者关账检查时先查这张表可以避免取到未结账期间的波动数据对审计场景非常有用。4.3 财务模块的扩展表结构除了总账核心表U8财务模块还包含应收应付、固定资产、工资等子模块它们各自有一组以模块缩写开头的表。应收表通常以 ar 开头应付表以 ap 开头固定资产表以 fa 开头工资表以 wa 开头。表名中文含义关键字段说明ar_detail应收明细账记录应收单、收款单等明细ap_detail应付明细账记录应付单、付款单等明细fa_cards固定资产卡片固定资产卡片主表wa_gzdata工资数据表工资项目数据应收应付、固定资产这些模块的表名和字段在不同版本之间变化比较大我一般建议按“模块前缀业务动作”的方式来记忆真正开发时再通过数据库自带的中文注释或字典工具确认具体字段。5. 手把手实操用SQL Server快速“摸”清表结构5.1 打开账套库的表清单用友U8的数据存放在SQL Server中打开 SQL Server Management Studio连接到U8对应的数据库实例展开“数据库”节点找到 UFDATA_001_2024 这样的账套库点击“表”节点就能看到成百上千张表。如果表数量太多眼睛看不过来可以用SQL语句直接搜索。SELECT t.name AS 表名, ep.value AS 表说明 FROM sys.tables t LEFT JOIN sys.extended_properties ep ON ep.major_id t.object_id AND ep.minor_id 0 WHERE t.name LIKE %PO% ORDER BY t.name;这段脚本的作用是找出所有表名中包含 PO 的表同时把表的中文说明也带出来。用友U8在创建数据库时大部分表都写了扩展属性作为中文注释所以查看扩展属性比盲猜表名靠谱很多。查询字段信息也类似用系统视图可以一次性把字段名、数据类型、中文说明全部拿出来。SELECT c.name AS 字段名, t.name AS 数据类型, ep.value AS 字段说明 FROM sys.columns c JOIN sys.types t ON c.user_type_id t.user_type_id LEFT JOIN sys.extended_properties ep ON ep.major_id c.object_id AND ep.minor_id c.column_id WHERE c.object_id OBJECT_ID(rdrecord) ORDER BY c.column_id;运行这段SQLrdrecord 表的所有字段、类型和中文注释就一目了然了。我最开始整理对照表时就是用这种方法把常用表的字段说明批量导出来再结合业务场景按模块归档效率比一个一个表翻高很多。5.2 主表和子表的关联关系怎么判断U8的业务表几乎都是“主表子表”的组合主表存单据头子表存单据体关联字段通常有两种常见命名方式。第一种是子表直接用一个“主表名ID”的字段关联主表比如 PO_Podetails 表中的 iPOID 就对应 PO_Pomain 表中的 cPOID。第二种是使用简化的关联字段比如 rdrecords 表中的 rdid 对应 rdrecord 表中的 ID。判断主表和子表关系最靠谱的方法是先看主键和外键约束。SQL Server 的 sys.foreign_keys 视图会展示表之间的外键关系如果表设计时创建了外键直接查询就能看到完整的关联链路。SELECT fk.name AS 外键名, tp.name AS 主表, ref.name AS 子表 FROM sys.foreign_keys fk JOIN sys.tables tp ON fk.referenced_object_id tp.object_id JOIN sys.tables ref ON fk.parent_object_id ref.object_id WHERE tp.name PO_Pomain ORDER BY fk.name;但在实际账套中不一定所有表都建了外键很多时候只有索引而没有外键约束。这种情况下就得靠字段命名的规律来推断主表的ID字段通常是单据主键子表中带同样业务含义的字段就是关联外键。我自己的判断顺序是先看字段名再看索引最后看数据内容。5.3 快速生成属于你自己的“业务级字典”依赖官方文档或者网上现成的表名对照始终不如自己动手整理一份适合当前项目的字典。我的做法分三步第一步写脚本导出所有表的字段和说明保存成Excel底稿。第二步按业务模块对表进行分类采购类、销售类、库存类、财务类、基础档案类各建一个Sheet把核心表放在前面。第三步每整理一张表就随手写一条验证SQL比如 SELECT TOP 100 * FROM 表名确认这张表实际存储的数据和表名含义一致。Excel底稿里我还会加一列“常用关联表”把经常一起联表查询的表名记录下来。比如销售订单主表 SO_SOMain 的常用关联表是客户档案 Customer、存货档案 Inventory、发货单主表 DispatchList。这样后续开发新报表时直接翻底稿就能找到该关联的路径。这个过程不需要一次性做完平时开发报表时遇到一张新表就补充一次坚持几个月后你会拥有一份比厂商标准文档还要贴合自己项目的表结构字典。6. 常见问题排查与避坑实录6.1 表名搜不到怎么办有次在客户环境里做二次开发我按习惯写 SELECT * FROM PO_Pomain结果SQL Server报“对象名无效”。当时第一反应是表不存在后来排查发现系统安装的是U8的轻量化版本采购订单表名被改成了 PU_ 前缀。U8不同版本、不同产品线之间的表名确实存在差异遇到搜不到的情况先不要怀疑自己记错了优先用模糊查询在系统库中搜索。SELECT t.name AS 表名, ep.value AS 表说明 FROM sys.tables t LEFT JOIN sys.extended_properties ep ON ep.major_id t.object_id AND ep.minor_id 0 WHERE t.name LIKE %Order% OR t.name LIKE %Pomain% OR t.name LIKE %PO% ORDER BY t.name;搜索时多换几个关键词中文拼音首字母、英文单词、模块缩写都可以试一遍。另外也要确认当前选中的数据库是否正确很多“表名无效”的报错其实是因为连接到了 master 库或者另一个账套库。6.2 联表查询数据翻倍做报表时最常见的问题就是联表后数据突然变多。我在处理采购订单和入库单的关联时遇到过这种情况。根本原因是一张主表对应多张子表如果同时关联两张子表数据行数就会成倍放大。举个具体例子PO_Pomain 是采购订单主表PO_Podetails 是采购订单子表假设一张订单有3行明细。如果要把采购订单和到货单关联而到货单子表有2行数据那么直接联表后这张订单会变成6行。解决方法是先分别做订单明细汇总和到货明细汇总再在汇总结果上进行关联避免底层单据明细发生笛卡尔积。我整理了一个报表取数原则明细对明细关联时先从业务上确认关联层级一致不一致时先做子查询聚合再关联主表。这条原则在U8所有模块的报表开发中都适用。6.3 大小写、编码和备份恢复问题SQL Server默认对表名不区分大小写所以 PO_Pomain 和 po_pomain 在SQL Server里是一样的。但如果你把数据导出到MySQL这类对大小写敏感的环境中就要特别注意表名的大小写保持一致。MySQL 8.4 的表名大小写问题尤其容易踩坑导出时最好统一为小写避免后续维护时的混乱。编码方面U8的数据库通常使用中文排序规则比如 Chinese_PRC_CI_AS。从外部导入数据时如果目标表字段类型是 varchar 而数据里有生僻字或特殊符号容易出现乱码。遇到这种情况优先检查排序规则是否一致或者把字段类型改成 nvarchar 再导入。备份恢复的坑更隐蔽。恢复U8账套备份后如果只恢复了账套库而没有同步更新UFSystem系统库中的账套信息U8客户端会提示账套不存在。正常流程是恢复账套库后在系统管理里执行“升级SQL Server数据库”操作让系统库和账套库的版本信息重新对齐。这一点对经常做环境迁移的同学尤其重要。6.4 金额对不上先查币种和汇率财务对账时经常发现系统里的金额和数据库查出来的金额差很多很多情况下不是取数逻辑错了而是币种和汇率字段没有处理。U8的业务单据同时支持多币种核算单据上的金额可能是原币金额也可能是本币金额。查询销售发票时需要同时关注币种字段和汇率字段。如果只看原币金额不做本币折算汇总出来的数据和财务账面的本位币金额必然对不上。遇到金额差异先看表里有没有币种字段 cCurCode再看有没有汇率字段 iExchRate然后确认当前统计口径是本位币还是原币。6.5 单据类型字段的隐藏逻辑库存模块的 rdrecord 表里单据类型字段 cVouchType 或类似字段决定了这条记录属于采购入库、销售出库、调拨出入库还是其他类型。直接对这个字段做过滤可以快速实现按单据类型统计。但单据类型在U8不同版本中维护方式不同有的是编码01代表采购入库、02代表销售出库有的是以具体单据名称存储。踩过坑之后我建议写SQL时先对单据类型字段做一次 GROUP BY看看当前版本里到底有哪些取值再写WHERE条件不要拿着旧版本的编码逻辑直接套用。我个人在实际操作中最深的一点体会是表名对照表不是整理一次就完事的东西而是需要跟着项目版本和业务范围持续更新的活文档。每做完一个报表、每排查完一个数据问题把新碰到的表名、字段和关联关系补充进去这本手册才会越用越顺手。后续如果你手头正好有U8环境我建议你花一个下午跑一遍文中提到的几条查询SQL把当前版本的常用表结构导出来亲手整理一遍比看十篇文档都管用。
 版本发布记录：变更清单、分发资产与 nodejs.org 仓库中的发布博客流水线)
