简介这份《用友数据库表名.doc》面向用友财务软件的运维人员、二次开发者和数据分析人员用于快速查阅系统底层数据表结构解决账务、库存、成本等模块表名含义不清、开发取数困难的问题。资源包共1个doc文件约30KB以表格形式集中罗列表名与中文说明便于检索和对照。内容覆盖总账、应收应付、成本会计、库存盘点等核心模块如AccInformation帐套参数表、Ap_Sum应收应付总账表、Ar_BadAge坏账计提账龄期间表、ArrivalVouch到货质检单主表、CA_系列成本分配与费用表、CheckVouch盘点单主表等并标注了主表与子表的关联关系。读者可据此理解用友数据库的整体结构为报表定制、数据抽取和系统维护提供参考。目前已有108人学习适合需要深入用友数据层的技术人员查阅。1. 用友数据库表名速查433 张表背后的账套结构长什么样接手一套用友 U8 的二次开发或数据迁移任务时最先卡住人的往往不是 SQL 语法而是面对 SQL Server 里几百张表不知道从哪张下手。这份《用友数据库表名.doc》把 433 张核心表的 TableID、ETableName、CTableName 三列对齐列出等于给了一套账套库的“地图索引”。它解决的不是某个具体功能而是让你在写查询、做报表取数、排查单据异常时能快速定位到 Ap_Vouch、GL_accvouch、RdRecord 这类关键表而不是靠猜表名。适合做用友二次开发、数据接口对接、财务数据抽取以及需要直接读库做对账的运维和 BI 人员。文档本身是静态清单但用法决定了它是速查表还是脚手架。2. 表名命名规律从前缀到主子的拆解逻辑2.1 模块前缀决定业务域用友这套表名不是随便起的前缀基本对应业务模块。摸清前缀等于先把 433 张表切成十几块检索范围立刻缩小。前缀业务域典型表GL_总账GL_accvouch、GL_accsum、GL_accassAp_ / Ar_应付 / 应收Ap_Vouch、Ap_Detail、Ar_BadParaCA_成本核算CA_ComPD、CA_DepCs、CA_RptSumfa_固定资产fa_Cards、fa_Depreciations、fa_VouchersWA_工资WA_GZData、WA_GZHZB、WA_SDSPO_ / PP_采购 / 生产计划PO_Pomain、PP_MPSmainSA_ / SO_销售SA_Account、SO_SOMainIA_ / Rd_存货核算 / 收发记录IA_Subsidiary、RdRecordFD_资金管理FD_AccSum、FD_CredUa_系统管理Ua_user、Ua_account、Ua_period拿到一张陌生表先看前缀判断它属于哪个模块再去对应模块的主表附近找关联比全库搜列名快得多。常见做法是先把这张表按前缀归类再结合 CTableName 的中文注释确认用途。2.2 主表与子表的配对规律文档里大量出现成对表名规律很稳定主表存单据头子表存单据体子表通常在主表名后加 s 或 _Sub。Ap_Vouch应付/收单主表→ Ap_Vouchs关联子表ArrivalVouch到货单主表→ ArrivalVouchs子表DispatchList发货单主表→ DispatchLists子表PurBillVouch采购发票主表→ PurBillVouchs子表SaleBillVouch销售发票主表→ SaleBillVouchs子表写联查时主子和表一般通过 ID 字段关联子表里通常有 MainID 或对应主表主键的外键列。实际字段名各版本略有差异但配对关系不会变。知道这个规律看到一张主表就能推断出子表大概叫什么反向也成立。2.3 临时表与正式表的区分文档里带 _tmp、_temp、_Bak、_pre 后缀的要特别小心。CA_Batchmx_temp、CA_bmmx_tmp、SaleRelation_Bak、fa_DeprVouchers_pre 这类表要么是中间计算过程要么是备份或准备态数据不是业务最终落库位置。做数据抽取时如果误把这些当正式表取出来的数要么是半成品要么是历史残留。判断方法很简单正式业务表在文档里都有明确中文注释临时表往往注释为空或只写“临时”“备份”。3. 按业务场景定位表四类高频查询的取数路径3.1 凭证与总账取数查凭证数据核心落在 GL_accvouch凭证及明细帐和 GL_accsum科目总帐。GL_accvouch 存的是分录级明细一行一条分录GL_accsum 是按科目期间汇总后的余额。做科目余额表取 GL_accsum做凭证明细导出取 GL_accvouch。-- 查某期间某科目的凭证明细 SELECT cVouchID, iPeriod, cDigest, cCode, md, mc FROM GL_accvouch WHERE iPeriod 202401 AND cCode LIKE 1122% ORDER BY cVouchID, iNid;iPeriod 是会计期间格式通常是年月cCode 是科目编码用 LIKE 做前缀匹配能覆盖下级科目md 和 mc 分别是借方和贷方金额。注意 GL_accvouch 里同一张凭证的多条分录共享 cVouchID按它排序能还原凭证顺序。如果查不到数据先确认账套库选对了没有再确认 iPeriod 的格式和账套启用期间是否匹配。3.2 应收应付与核销追踪应收应付的核心表是 Ap_Vouch / Ap_Vouchs应付和对应的应收侧核销情况在 Ap_Cancel账龄分析依赖 Ap_BillAge 和 Ar_BadAge。做应收账龄或核销明细时常见路径是从 Ap_Detail应收/付明细帐出发关联 Ap_Cancel 拿核销记录。-- 查某客户未核销的应收明细 SELECT d.cCusCode, d.cVouchID, d.iAmount, d.iBalance FROM Ap_Detail d LEFT JOIN Ap_Cancel c ON d.cVouchID c.cVouchID WHERE d.cCusCode C001 AND c.cVouchID IS NULL;cCusCode 是客户编码iAmount 是原始金额iBalance 是余额。用 LEFT JOIN 加 IS NULL 筛出没有核销记录的行就是未核销明细。这里有个坑Ap_Cancel 里同一张单据可能有多条部分核销记录直接 JOIN 会放大行数正确做法是先按 cVouchID 聚合核销金额再比对。3.3 库存与收发记录库存取数绕不开 RdRecord收发记录主表和 RdRecords子表现存量在 CurrentStock存货明细账在 IA_Subsidiary。查某仓库某存货的出入库流水从 RdRecord 关联 RdRecords 即可。-- 查某存货近期的收发流水 SELECT r.cCode, r.dDate, r.cVouchType, s.cInvCode, s.iQuantity FROM RdRecord r INNER JOIN RdRecords s ON r.cVouchID s.cVouchID WHERE s.cInvCode M001 AND r.dDate 2024-01-01 ORDER BY r.dDate;cVouchType 区分单据类型采购入库、销售出库等iQuantity 是数量。RdRecord 和 RdRecords 通过 cVouchID 关联。注意收发记录里有些单据是红字冲销数量为负做汇总时别直接 SUM 就完事要结合 cVouchType 判断方向。3.4 固定资产卡片与折旧固定资产模块的表以 fa_ 开头核心是 fa_Cards卡片、fa_Depreciations折旧方法、fa_DeprTransactions折旧和 fa_Vouchers变动单。查某资产的折旧历史从 fa_Cards 拿资产编号再去 fa_DeprTransactions 取各期折旧额。-- 查某资产的折旧记录 SELECT c.CardID, c.cAssetName, t.iPeriod, t.iDeprAmount FROM fa_Cards c INNER JOIN fa_DeprTransactions t ON c.CardID t.CardID WHERE c.CardID A0001 ORDER BY t.iPeriod;CardID 是卡片主键iPeriod 是折旧期间iDeprAmount 是折旧额。fa_DeprTransactions 只存已计提的折旧如果某期没数据要么是没计提要么是资产已处置。fa_CardsSheets 是卡片 Sheets 表做卡片明细展示时会用到别和 fa_Cards 搞混。4. 避坑与排查读用友库最容易翻车的五个地方4.1 账套库和系统库混用现象查 Ua_user 能查到用户但查 GL_accvouch 报对象不存在。原因Ua_ 系列表在系统库UFSystemGL_、Ap_ 等业务表在账套库UFDATA_xxx。解决先确认当前连接的是哪个库跨库查询要么切库要么用全限定名。我一般会先SELECT DB_NAME()确认再动手写 SQL。4.2 年度账套库选错现象明明有凭证按期间查却一条都查不到。原因用友按年度分账套库2023 年的数据在 UFDATA_001_20232024 年在 UFDATA_001_2024连错库自然查不到。解决确认目标年度连对应年度库。做跨年报表时要么分别查再合并要么用链接服务器。4.3 主子表关联字段想当然现象JOIN 之后行数暴涨或数据对不上。原因不同模块主子表关联字段名不统一有的用 ID有的用 cVouchID有的用 MainID。解决先各查一张主表和子表的前几行肉眼确认关联列再写 JOIN。别照着别的模块的字段名硬套。4.4 临时表当正式表用现象取出来的数据时有时无或者金额明显不对。原因查到了 _tmp、_temp、_Bak 后缀的表。解决对照文档里的中文注释注释为空或写“临时”的一律不用。正式业务表都有明确的中文名这是最快的判断依据。4.5 金额字段正负号理解错现象应收汇总出来是负数或者借贷方向反了。原因用友很多金额字段用正负号表示方向md/mc、iAmount 在不同表里含义不同。解决先拿一张已知单据核对确认字段的正负规则再写汇总。GL_accvouch 里 md 是借方、mc 是贷方但 Ap_Detail 里的 iAmount 可能带方向不能一概而论。5. 把表名清单变成可用工具三个进阶技巧5.1 用 Power Designer 反向生成表关系图文档给的是表名清单但真正做开发时光知道表名不够还得知道表之间怎么关联。常见做法是用 Power Designer 或类似工具连上账套库反向工程生成物理模型把 433 张表的字段和主外键关系可视化。生成之后对照这份文档的 CTableName 列补中文注释模型可读性会高很多。注意反向工程时只选业务表把 _tmp、_Bak 和系统表排除掉否则图会乱到没法看。5.2 建一张本地映射表做速查与其每次翻文档不如把这份清单导入本地数据库建一张表名映射表加上模块前缀和业务域两列之后写 SQL 前先查一下。CREATE TABLE TableNameMap ( TableID INT PRIMARY KEY, ETableName NVARCHAR(100), CTableName NVARCHAR(200), ModulePrefix NVARCHAR(20), BusinessDomain NVARCHAR(50) ); INSERT INTO TableNameMap (TableID, ETableName, CTableName, ModulePrefix, BusinessDomain) VALUES (23, Ap_Vouch, 应付/收单主表, Ap_, 应付管理);ModulePrefix 用 ETableName 的前缀截取BusinessDomain 按模块归类。之后遇到陌生表先SELECT * FROM TableNameMap WHERE ETableName xxx确认用途比翻文档快。这个映射表还能扩展加上常用关联字段和备注慢慢就变成自己的知识库。5.3 用 INFORMATION_SCHEMA 做存在性校验文档是静态的实际账套库里的表可能因为版本差异、模块未启用等原因和清单对不上。写脚本前先校验目标表是否存在避免跑一半报错。-- 校验文档里的表在实际库中是否存在 SELECT t.ETableName, CASE WHEN i.TABLE_NAME IS NOT NULL THEN 存在 ELSE 缺失 END AS Status FROM TableNameMap t LEFT JOIN INFORMATION_SCHEMA.TABLES i ON t.ETableName i.TABLE_NAME WHERE i.TABLE_TYPE BASE TABLE OR i.TABLE_NAME IS NULL;这个查询能快速筛出哪些表在当前账套里没有可能是模块没启用也可能是版本差异。做数据迁移前跑一遍心里有底不会写到一半才发现某张表根本不存在。从那以后我每次接手新账套都强制先跑一遍表存在性校验再对照这份清单确认模块范围最后才动手写取数逻辑。这套顺序帮我省掉了大量返工。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助?