致远OA V8.1数据字典：读懂字段业务含义的普通话词典

简介本资源是致远OA V8.1官方版本配套的结构化数据字典PDF文档面向OA系统二次开发人员、数据库管理员及低代码平台集成工程师用于快速掌握核心业务表结构与字段语义解决开发对接中因字段含义不清、类型不明确导致的接口异常、数据映射错误等问题。文档以ADDRESSBOOK等关键表为范例完整呈现主键约束、必填标识、扩展字段分组文本/数字/日期/枚举/选人/选部门/选岗位共7类及业务注释覆盖50扩展属性的设计逻辑与使用边界。资源为单文件PDF格式大小2.2MB轻量易读适合作为开发手册随查随用。目前已有2606人学习下载可直接用于数据库建模参考、SQL脚本编写、流程引擎字段绑定及系统升级兼容性分析显著提升致远OA定制化开发效率与数据治理规范性。1. 致远OA V8.1 数据字典不是说明书而是你和系统之间的“普通话词典”想象一下你刚接手一个老同事留下的OA系统——界面熟悉流程能跑但一打开数据库满屏都是ADDRESSBOOK_SET_SCOPE、AI_DEAL_CONDITION、ATTENDANCE_NO_REMIND_MEMBER这类名字。你查字段EXT_ATTR_47它存的到底是“审批人ID”还是“抄送人岗位编码”改个导出逻辑结果把ZX_DISPLAY_COLUMN致信专用显示列误当成DISPLAY_COLUMN通用显示列导出的通讯录在手机端全乱了……这种“看得见表名、读不懂含义”的状态就是没数据字典的真实写照。致远OA V8.1 数据字典不是一份技术文档更不是给DBA看的建表SQL清单它是整套OA系统里所有数据库表、字段、约束、业务含义的权威汉语翻译本。它把系统内部用的“数据库黑话”一句句翻成你能拍着桌子说清楚的话比如TYPE SMALLINT TRUE不是“类型是小整数”而是“这个组必须是系统组0、个人组1或私人通讯录2三选一缺一不可”CANCEL_FLAG SMALLINT FALSE也不是“取消标记可为空”而是“一旦代理被取消这里就记1后续所有流程都绕开这个人——哪怕他还在组织架构里”。为什么值得花时间搞懂它因为你在做这五件事时90%的翻车都源于没查它写报表时连错表把ADDRESSBOOK_MEMBER当成ADDRESSBOOK主表漏掉外部联系人关联逻辑做接口时传错字段把MEMBER_ID当作用户登录账号实际它只是内部人员编号配置考勤规则时填反值IS_WORKDAY0是“非工作日”但你按常识理解成“未设置”结果全员旷工扩展字段乱用把EXT_ATTR_31枚举当EXT_ATTR_1文本存长字符串字段直接截断升级后功能异常V8.1 新增AI_ORG_CHANGE_RECORD表记录部门变更但旧脚本还去查已废弃的ORG_HISTORY。它不教你写代码但它能让你写的每一行SQL、每一个API参数、每一次配置修改都踩在系统设计的真实路基上——而不是靠猜、靠试、靠重启服务器碰运气。2. 它到底是什么一张表、一个字段、一行注释全在讲“业务怎么活”2.1 表不是容器是业务场景的切片在致远OA V8.1里一张表从来不是孤立的数据集合而是对某个具体管理动作的完整快照。以ADDRESSBOOK通讯录主表为例它不叫“联系人表”而叫“通讯录”——这意味着它承载的不是静态信息而是动态协作关系。MEMBER_ID字段标为FALSE非强制是因为通讯录既要存内部员工有MEMBER_ID也要存客户、合作伙伴等外部联系人此时MEMBER_ID为空靠NAMECOMPANY_NAME唯一识别而ADDRESSBOOK_MEMBER表里的CREATOR_ID和CREATOR_NAME必填是因为每条外部联系人记录必须明确“谁在系统里亲手加的这个人”这是审计溯源的硬要求。再看考勤模块的ATTENDANCE_DAY_STATISTICS签到日统计表AM_START_STATE和PM_END_STATE类型都是SMALLINT取值却不是0/1而是有明确定义1正常、2迟到、3早退、4旷工、5外勤、6缺卡……这些数字背后没有魔法全靠数据字典里那句注释“上午签到结果”。它把数据库里冰冷的数字直接锚定到HR每天晨会说的“张三今天上午迟到了”。关键点当你看到一张表名先问自己——这个业务动作在办公室里是谁、在什么场景下、为什么要做答案就在表注释里。AGENT表注释写的是“代理设置应用表”不是“代理人表”说明它的核心价值不是存人而是存“谁在什么时间段替谁处理哪类事务”的授权契约。2.2 字段不是变量是业务规则的晶体化表达数据字典里每个字段的“数据类型强制注释”合起来才是一条完整业务规则。拆开看数据类型是底线EXT_ATTR_11 DECIMAL(19,4)看似只是“存数字”但(19,4)意味着它能存最大999999999999999.9999的数——为什么这么设计因为致远OA里某些绩效分值要精确到小数点后4位如“领导力评估4.9999分”少一位就会四舍五入失真。强制TRUE/FALSE是红线ID BIGINT TRUE不仅是主键要求更是系统底层校验逻辑的开关——如果某条ADDRESSBOOK_TEAM记录的ID为空整个团队分组功能会直接报错退出而不是默默跳过。注释是灵魂TYPE VARCHAR(50) FALSE后面那句“0系统组 1个人组 2私人通讯录”比任何代码注释都管用。它告诉你这个字段不是随便填的字符串而是有且仅有三个合法值的枚举项填3或abc系统不会存也不会报错而是静默转成空值——然后你的“私人通讯录”功能就永远找不到了。提示所有EXT_ATTR_*扩展字段共70个都不是备用字段池。它们是致远OA预留的“业务插槽”EXT_ATTR_31~40专供下拉枚举如“紧急程度高/中/低”EXT_ATTR_41~50专供选人组件如“法务审核人”EXT_ATTR_51~60专供选部门如“预算归口部门”。混用即失效——把选人字段当文本字段存前端就无法联动组织架构树。2.3 约束不是限制是业务语言的语法数据字典里没有显式写出“外键约束”“唯一索引”但字段间的逻辑关系早已藏在命名和注释中ADDRESSBOOK_SET_SCOPE表里ADDRESSBOOK_SET_ID字段注释写“通讯录设置 ID”而ADDRESSBOOK_SET表的ID是主键——这就是隐式外键没有它SET_SCOPE就是无源之水AI_DEAL_CONDITION表中SENDER_ID和USER_ID都标为BIGINT FALSE但注释分别写“发起人 ID”和“处理人 ID”意味着同一笔流程里这俩ID可以相同自审自批也可以不同跨岗审批但绝不能同时为空——否则系统无法判断“谁发的、谁该办”。这些不是DBA该操心的性能优化点而是你写业务逻辑时的语法检查器。比如开发一个“自动催办”功能你要查AI_REMIND_RECORD表就必须先确认REMIND_AFFAIR_ID对应的是AFFAIR表里的有效事项ID——数据字典不写“外键”但REMIND_AFFAIR_ID的注释“被查看的已办或已发事项 ID”已经告诉你它必须指向一个真实存在的事项否则催办消息发出去收件人点开就是404。3. 它为什么存在解决OA系统里最痛的三个“不知道”3.1 不知道“这个字段到底管什么”——告别字段名玄学新手最容易栽在字段名上。比如ATTENDANCE_INFO表里的PUNCH_TYPE字段名是“打卡类型”但数据字典写明“排班类型0-固定排班1-周期排班”。如果你只看名字可能以为它存的是“手机打卡/指纹打卡/人脸识别”实际上它决定的是整个考勤计算逻辑固定排班走日历匹配周期排班走7天循环模板。填错值员工本月考勤全部算错。再如BBS_ARTICLE表的SPACETYPE名字像“空间类型”但注释写清“1部门2单位3集团4自定义团队17自定义单位18自定义集团”。这意味着当你要查“集团级公告”不能WHERE SPACETYPE 3而必须WHERE SPACETYPE IN (3,18)——因为“自定义集团”也是集团空间的一种但名字里没体现。数据字典把这种“名字像A、实际是B”的陷阱全摊开在阳光下。它不假设你知道行业黑话而是用最直白的业务语言重写一遍。3.2 不知道“改这里会不会崩其他功能”——看清字段的辐射半径OA系统最怕“牵一发而动全身”。数据字典帮你画出每个字段的影响地图ADDRESSBOOK_SET表的VIEW_SCOPE字段查看范围注释写“查看范围”看似简单。但往下看ADDRESSBOOK_SET_SCOPE表你会发现它通过ADDRESSBOOK_SET_ID关联并按USER_TYPE组织模型实体类型细分权限。这意味着改VIEW_SCOPE不仅影响通讯录列表展示还会同步控制ADDRESSBOOK_SET_SCOPE里所有USER_TYPEDEPARTMENT的部门可见性。AGENT表的AGENT_TYPE字段代理类型注释写“1-代理设置 2-离职交接”。这直接决定AGENT_DETAIL表里APP字段的取值逻辑AGENT_TYPE1时APP存的是应用ID如“公文”“合同”AGENT_TYPE2时APP固定为0表示全系统交接。改错这里离职交接单可能只流转到公文模块合同审批却没人处理。它不告诉你“技术上怎么改”但明确标注“改这个会影响哪些表、哪些业务流”。就像修电路前先看接线图——你知道EXT_ATTR_21日期类型扩展字段1被ATTENDANCE_ARRANGE和AI_PROCESSING_CONDITION两个模块共用就不会在考勤排班里随便删它。3.3 不知道“新功能用哪个表”——快速定位业务模块的入口V8.1 新增了AI相关表AI_*前缀但没人告诉你它们怎么用。数据字典就是你的功能导航仪AI_ORG_CHANGE_RECORD注释是“组织变更记录”字段OLD_VALUE/NEW_VALUE存变更前后的文本值ORG_TYPE标明是部门/岗位/职务级别——这说明它是做组织架构异动审计的不是用来查当前部门树的AI_PROCESSING_CONDITION注释“自动处理条件”CONDITION_VALUE类型是TEXT注释写“自动处理条件”——结合V8.1升级说明它存的是JSON格式的规则引擎表达式如{field:status,op:eq,value:approved}用于配置“审批通过后自动归档”这类动作AI_REMIND_COUNT和AI_REMIND_RECORD是一对前者存“被催办次数”后者存“谁催的、催了几次、是否已发消息”。这意味着做催办统计报表必须两表JOIN且IS_SEND_MSG1才是有效催办。没有数据字典你可能花三天研究AI_DEAL_CONDITION最后发现它只在流程引擎内部调用根本不对外开放API有了它你一眼锁定AI_REMIND_RECORD两小时就做出催办漏斗分析。4. 怎么区分别再把数据字典、数据库ER图、接口文档搞混了4.1 数据字典 vs 数据库ER图一个讲“意思”一个讲“结构”维度数据字典致远OA V8.1数据库ER图核心目标解释每个字段“在业务里代表什么、怎么用、为什么这样设计”描绘表与表之间“谁引用谁、一对多还是多对多”你查它时想问“EXT_ATTR_61能不能存岗位名称填错会怎样”“ADDRESSBOOK_TEAM和ADDRESSBOOK_TEAM_MEMBERS怎么关联”关键内容字段注释、强制性、数据类型精度、枚举值含义、业务场景说明表名、字段名、主键/外键连线、基数1:1, 1:N典型错误把ER图当字典用看到ADDRESSBOOK_TEAM.ID → ADDRESSBOOK_TEAM_MEMBERS.TEAM_ID就以为TEAM_ID可以为空实际数据字典写明FALSE把字典当ER图用在AGENT_SCOPE表里找ENTITY_ID的外键指向却发现注释只写“对应 ENTITY_TYPE 中的实体 ID”没写具体关联哪张表通俗地说ER图是建筑的钢筋骨架图纸告诉你梁柱怎么搭数据字典是装修说明书告诉你“这个开关控制客厅灯那个插座专供空调别把冰箱插头塞进厨房插座”。4.2 数据字典 vs 接口文档一个管“存什么”一个管“怎么拿”维度数据字典致远OA V8.1接口文档如REST API关注对象数据库表、字段、约束、业务含义API路径、请求方法、入参格式、返回JSON结构、错误码你查它时想问“ATTENDANCE_DAY_STATISTICS.AM_START_STATE的值2代表迟到那前端显示该用什么文案”“查员工考勤日报该调哪个URL参数传memberId还是userId”关键内容AM_START_STATE SMALLINT 注释“上午签到结果1正常2迟到…”GET /api/v1/attendance/daily?memberId12345 返回示例{ amStartState: 2, stateText: 迟到 }典型错误用接口文档替代字典看到API返回stateText迟到就以为数据库里也存字符串结果去ATTENDANCE_DAY_STATISTICS表里搜迟到永远找不到实际存的是数字2用字典替代接口文档查到BBS_ARTICLE.REPLY_NUMBER是“回复数”就直接SELECT REPLY_NUMBER FROM BBS_ARTICLE却不知接口已做权限过滤只返回当前用户有权限看的帖子打个比方数据字典是菜市场的价目表青菜5元/斤猪肉38元/斤接口文档是外卖App的下单按钮点“青菜”弹出规格选择点“提交”才真正扣款。你不能看着价目表就以为能直接扫码支付。4.3 数据字典 vs 系统配置手册一个讲“数据本质”一个讲“操作步骤”维度数据字典致远OA V8.1系统配置手册核心价值揭示数据背后的业务规则和设计意图指导管理员在Web后台点哪里、填什么、保存后生效范围你查它时想问“ATTENDANCE_SETTING.AVAILABLE0是禁用围栏那AVAILABLE1是启用还是启用默认开启”“怎么在后台设置考勤围栏第几步点‘启用’按钮”关键内容AVAILABLE SMALLINT FALSE 注释“是否启用0否1是”截图步骤“1. 进入【考勤管理】→【围栏设置】2. 勾选‘启用地理围栏’3. 输入经纬度范围…”典型错误把配置手册当字典手册说“勾选启用”你就以为数据库AVAILABLE字段填1就行却不知ATTENDANCE_SETTING表还有LONGITUDE/LATITUDE字段必须非空否则启用无效把字典当配置手册查到BBS_BOARD.ANONYMOUS_FLAG0是允许匿名就直接UPDATE数据库结果因未触发后台缓存刷新前台还是显示“不允许”注意配置手册是“怎么做”数据字典是“为什么这么做”。比如ADDRESSBOOK_SET.EXPORT_PRINT字段手册教你怎么在后台勾选“允许导出”字典告诉你这个字段值为1时ADDRESSBOOK_SET_SCOPE表里对应范围的用户才能看到导出按钮——没它勾选了也白搭。5. 什么时候用、什么时候别用我的血泪经验总结5.1 必须查数据字典的5个生死时刻场景1写SQL报表字段值对不上业务需求某次给HR做“近3个月考勤异常分析”我写了这条SQLSELECT MEMBER_ID, COUNT(*) as late_count FROM ATTENDANCE_DAY_STATISTICS WHERE AM_START_STATE 2 -- 迟到 AND PUNCH_DATE 2024-01-01 GROUP BY MEMBER_ID;结果导出的“迟到人数”比HR手工统计少了一半。查数据字典才发现AM_START_STATE2确实是迟到但ATTENDANCE_DAY_STATISTICS表只存“当日有打卡记录”的数据而很多员工迟到后根本没打卡他们的异常记录在ATTENDANCE_HISTORY表里TYPES1签到且STATES3上班迟到。教训只要报表涉及“异常统计”必须对照字典确认异常状态是存在主统计表还是分散在历史流水表ATTENDANCE_DAY_STATISTICS注释写的是“签到日统计表”ATTENDANCE_HISTORY注释是“打卡历史”一字之差数据源天壤之别。场景2配置新流程节点参数总报错给合同模块加“法务终审”节点需要指定审批人。我在流程设计器里填EXT_ATTR_41选人类型数据字段但保存时报“人员ID不存在”。查字典发现EXT_ATTR_41的注释是“选人类型数据字段”但没写清楚它存的是单个ID还是ID列表。翻到ADDRESSBOOK_MEMBER表的CREATOR_ID同为选人字段注释写“创建人 Id”类型BIGINT TRUE——立刻明白EXT_ATTR_41只能存一个数字ID不能存逗号分隔的字符串。而流程设计器要求的是人员集合必须换用EXT_ATTR_41关联的ADDRESSBOOK_TEAM_MEMBERS表来实现多人审批。教训所有带“选人”“选部门”字样的扩展字段必须查清它是存ID单值、ID列表字符串、还是关联表ID需JOIN。字典里VARCHAR(50)类型基本排除ID列表可能长度不够BIGINT才是单值ID。场景3升级后功能异常排查范围太大V8.1升级后“通讯录共享给外部联系人”功能失效。我先查ADDRESSBOOK_SET表的EXTERNAL_SCOPE字段编外人员权限设置字典注释写“1按工作范围显示2全部隐藏”值是1没问题。再查ADDRESSBOOK_SET_SCOPE表发现USER_TYPEACCOUNT的记录里ADDRESSBOOK_SET_ID指向的设置ID其VIEW_SCOPE是2仅限本单位。原来EXTERNAL_SCOPE控制“是否对外”VIEW_SCOPE控制“对外看到什么”——两个字段必须协同生效。教训涉及权限的功能永远不是单字段问题。字典里凡是有“范围”“权限”“可见性”字样的字段必须顺藤摸瓜查关联表。ADDRESSBOOK_SET_SCOPE的注释“通讯录设置范围”就是明确提示你这里才是权限落地的最终执行层。场景4对接第三方系统字段映射总出错对接钉钉通讯录要把ADDRESSBOOK_MEMBER的MOBILEPHONE同步过去。我直接SELECT MOBILEPHONE FROM ADDRESSBOOK_MEMBER结果部分号码带86前缀部分不带钉钉校验失败。查字典发现MOBILEPHONE VARCHAR(20) FALSE注释是“手机”但没写格式规范。再翻BBS_ARTICLE_ISSUE_AREA表的MODULE_ID字段注释写“组织模型编号”类型BIGINT——立刻意识到致远OA里所有VARCHAR类型的号码字段都不做格式标准化必须由应用层清洗。教训VARCHAR类型的文本字段尤其是电话、邮箱、地址字典从不承诺格式统一。MOBILEPHONE存的是用户输入原值EMAIL可能大小写混用ADDRESS可能含换行符。对接时必须加清洗逻辑不能信字段名。场景5开发自定义报表想加个新维度却找不到表想统计“各岗位员工使用致信的活跃度”需要岗位ID。我查ADDRESSBOOK_MEMBER表有COMPANY_POST岗位但它是VARCHAR(50)文本字段无法和组织架构表关联。查字典发现AI_ORG_MEMBER_CHANGE表里有OLD_POST_ID/NEW_POST_ID岗位 ID注释是“旧岗位 ID”“新岗位 ID”类型BIGINT。再看ATTENDANCE_INFO表也有OWNER_ID打卡人ID但没岗位字段。最终方案用OWNER_ID关联ADDRESSBOOK_MEMBER.MEMBER_ID再通过ADDRESSBOOK_MEMBER的COMPANY_POST做模糊匹配——虽然不精准但字典确认了这是唯一可用的岗位信息源。教训当你要的字段不在主表先查所有AI_*AI相关、ATTENDANCE_*考勤相关、BBS_*社区相关表它们常存业务过程中的中间状态。AI_ORG_MEMBER_CHANGE注释“组织成员变更”就是岗位变更的黄金数据源。5.2 别用数据字典的3个危险区危险区1当它能替代测试字典写CANCEL_FLAG SMALLINT FALSE取消标记0-未取消 1-已取消我就以为设成1就万事大吉。结果上线后发现代理取消后AGENT_DETAIL表里对应的记录没清理导致流程还能走到已取消的代理人。查日志才发现系统取消代理时除了更新AGENT.CANCEL_FLAG还会调用存储过程清理AGENT_DETAIL。结论数据字典描述的是数据状态不是业务流程。状态变更的副作用如级联删除、缓存刷新、消息通知必须看代码或流程图字典不保证。危险区2当它能解释所有NULL值UPDATE_DATE DATETIME FALSE最后修改日期字典没写“何时为空”。我默认“新建记录时空”结果发现有些表的UPDATE_DATE在INSERT时不设值UPDATE时才更新有些表如BBS_ARTICLE的MODIFY_TIME在INSERT时就设为ISSUE_TIME。结论FALSE只代表数据库允许NULL不解释业务逻辑。UPDATE_DATE为空可能是“从未修改”也可能是“修改逻辑未触发”必须查代码或测试验证。危险区3当它能预测未来版本V8.1字典里AI_*表全标“AI相关”但没写清楚哪些是V8.1新增、哪些是V7.x遗留。我基于AI_DEAL_CONDITION开发了自动处理规则结果V8.2升级后这个表被废弃新逻辑移到PROCESS_RULE表。结论数据字典是当前版本的快照不是演进路线图。所有带AI_、M3_、ZX_前缀的表都要查版本发布说明确认生命周期字典本身不标注废弃状态。从那以后我每次接到需求第一件事不是打开数据库客户端而是打开这份《致远OA V8.1 数据字典》用CtrlF搜关键词把涉及的表、字段、注释、关联关系全抄到笔记里再动手写第一行代码。它不能代替思考但能让我避开90%的“我以为”陷阱。希望帮到你。本文还有配套的精品资源点击获取