简介：用友U9 ERP V2.5手册面向企业信息化实施顾问、ERP运维人员及财务与供应链管理者，聚焦用友最新SOA架构ERP的多组织、多架构、多会计应用场景，帮助读者理解这款被称为全球第一款SOA高端ERP的产品体系与功能边界。资源包共1个docx文件，约9.54MB，内容为U9 V2.5发版说明，系统梳理了产品概述、产品特性与关键技术特性，并覆盖财务、人力资源、制造、供应链、项目制造、成本、质量、协同门户及UAP平台等领域的应用范围与关键特征。读者可从中获取多组织协同、业务灵活性、全球化管理的设计思路，了解完全SOA架构在ESB、BPM、企业搜索与Office集成等方面的技术优势，以及各领域产品的功能清单与版本增量要点。目前已有345人学习，适合作为U9选型调研、实施准备与功能对照的参考材料。

1. 拿到一份 2012 年的 U9 V2.5 发版说明，我为什么还留着它

上周有个做集团财务共享的朋友问我，他们厂里那套老 U9 还在跑，最近想动审批流和凭证打印，翻遍内网只找到一份 2012 年 2 月的 V2.5 发版说明，问这东西还有没有参考价值。我让他先别急着找新版文档，把这份增量说明打开，翻到“审批结果的短路算法”和“凭证支持个性化”两节——他当场就愣住了，因为这两个点正好卡在他现在要改的地方。这份《用友U9_ERP_V2.5手册》不是操作手册，是 U9 V2.5 相对 2.1SP 的增量发版说明，覆盖财务、人力、制造、供应链、项目制造、成本、质量、协同、UAP 平台等 11 个领域 42 个产品的功能变更。它适合三类人：正在维护 U9 老版本的实施顾问、要给集团客户做二次开发的客开、以及需要判断某个功能“到底哪个版本才有”的运维。下面我按自己拆文档的顺序，把能直接抄的部分和容易翻车的地方讲清楚。

2. 先看清这份增量说明的边界：V2.5 到底改了什么

2.1 增量说明和全量手册的区别

很多人拿到“发版说明”就当成完整手册用，结果找一个基础档案字段找不到，就以为文档缺页。这份 V2.5 文档开头写得很明确：它是 V2.5 版本的增量发版说明，基线是 U9 2.1SP。也就是说，2.1SP 已有的功能它不会重复讲，只讲这半年在现场验证后新增或修改的部分。我一般会把它和 2.1SP 的手册并排放，遇到一个功能先问“这是新增还是修改”，新增的直接看本文档，修改的要看它改的是哪个模块的哪个节点。

从产品范围看，V2.5 覆盖财务 15 个产品、人力资源 3 个、供应链 6 个、生产制造 8 个、成本 2 个、项目制造 2 个，加上质量、基础设置、系统管理、协同门户和 UAP 平台。这个清单本身就是一张排查表：客户提的需求落在哪个产品下，就去对应章节找。比如“集中采购、分散收货”属于供应链的采购管理，“多账簿多币种成本计算”属于财务的成本会计，别跨模块乱翻。

2.2 技术架构对实施意味着什么

文档反复强调 U9 是全球第一款完全基于 SOA 架构的企业管理软件，底层是 UAP 平台，带企业服务总线 ESB、业务流程管理 BPM、企业搜索、报表工具，还支持和 Office（Word、Excel、Outlook）集成、支持 PDA 等手持设备。这些话听起来像宣传，但对实施有实际含义：U9 的功能扩展大多不是改代码，而是通过 UAP 的服务组件装配、个性化配置、报表设计器来完成。所以后面看到的“个性化”“报表设计器”“分录模板”这些章节，才是日常改动最常碰的地方，而不是那些领域功能列表。

提示：判断一个需求能不能在标准产品里做，先看它属于“配置能解决”还是“必须客开”。V2.5 文档里大量条目其实是把原来要客开的事变成了配置，比如报表数据源支持实体关联设计、打印模板按用户授权，这类条目价值最高。

2.3 把 42 个产品映射成一张排查表

我习惯把文档里的产品清单抄成一张表，左边写产品名，右边写这次 V2.5 有没有动它。动过的重点看，没动的说明这个版本别指望有新特性。下面这张表是我按文档整理的领域与产品对应关系，实际排查时直接按客户诉求定位：

这张表的作用不是背，而是当客户说“我要在采购订单上带出料品厂牌的弹性域”时，你能立刻判断这涉及基础设置的料品档案、供应链的采购管理、以及 UAP 的弹性域传值三块，而不是只翻采购章节。

3. 平台层能直接落地的配置：界面缩放、登录锁定与 Cookie

3.1 界面缩放开关怎么打开

V2.5 在 Portal 里加了界面缩放，采用通用调整算法支持卡片、单据、列表、报表缩放，但文档明确说“不是对所有界面都有效”，而且默认关闭。打开方式是改配置文件Portal\UBFConfig\UFSoft.UBF.UI.ReviseLayout.Config，把根节点的revise属性设为true。配置文件里列了所有可缩放的 Form，如果某个 Form 也要缩放，按列表行格式自己加一行，pageuri从 IE 导航栏取：进节点后 URL 里lnk=之后到&之前那段就是。

<!-- Portal\UBFConfig\UFSoft.UBF.UI.ReviseLayout.Config --> <ReviseConfig revise="true" inverse="false"> <!-- 每一行对应一个可缩放的 Form，pageuri 取自导航栏 lnk= 与 & 之间 --> <Form pageuri="UFSoft.UBF.UI.Portal.MainForm" /> </ReviseConfig>

逻辑说明：revise="true"是总开关，inverse控制缩放方向的反转，一般保持false。pageuri必须和导航栏里实际的值完全一致，多一个斜杠或少一个参数都匹配不上，表现就是“开关开了但那个界面没反应”。参数上要注意，这个功能默认关闭是有原因的——部分复杂报表缩放后列宽会错位，所以只对确认没问题的 Form 逐个加，不要图省事全量放开。

3.2 登录失败锁定与解锁的坑

系统管理→参数设置下新增了“输入密码超过一定次数便禁用用户登录”，体现在系统管理→用户下的活动按钮框：错误次数累积到阈值，系统自动把活动按钮的勾去掉。重新激活要用别的用户登录，把活动按钮重新勾上。文档里有一句 PS 很关键：错误次数是累计写入数据库的，累积到一定次数时，可能出现“只输错一次就被停用”的情况，需要重启 IIS。

我一般会提醒运维两件事：第一，阈值别设太小，集团环境里共享账号或代填密码的场景多，累计计数很容易被误伤；第二，解锁流程要写进值班手册，因为被锁的用户自己登不进去，必须找有权限的人操作。另外登录界面新增了操作日期，改日期可用关键字OpertaionDate从上下文取，做登录后跳转或默认日期逻辑时会用到这个键名，注意文档里拼写就是OpertaionDate，不是OperationDate，照抄别手改。

3.3 Cookie 有效期与批量审核工作台

系统应用的 Cookie 有效期默认 24 小时，可在系统管理→参数设置里改。这个参数直接影响用户体验：有效期太短，用户上午填一半的单据下午回来要重新登录；太长，共享终端上残留会话有风险。我的习惯是按岗位分：固定工位可以放长，车间或共享终端保持默认甚至缩短。

审批流这边，V2.5 加了批量审核工作台，把所有待审单据类型集成到一个页面，入口在 Portal 主菜单最右侧，可以设置审核动作和意见。配套还有“收回”——提交人在第一个审核人未审核前可以收回单据；“设置退回意见”——退回时能看到上级为什么退回。这几个功能组合起来，才是完整的审批闭环，单独配一个批量审核而不配退回意见，用户还是会打电话问“为什么退我”。

4. 审批流与凭证：短路算法、弃审逻辑和打印规则

4.1 审批短路算法怎么配才不误伤

文档给了一个很具体的案例：活动 A 需要 10 个人审核，其中 2 人同意则同意，1 人拒绝则拒绝。旧逻辑要 10 个人全部处理完才计算结果，新逻辑两人同意就立即转下一活动。这就是“短路算法”，本质是提前满足条件即终止当前活动。

配置时要想清楚三件事：同意阈值、拒绝阈值、以及未处理人的单据状态。阈值在活动节点上设，不是全局参数，所以同一个流程里不同活动可以有不同的短路规则。我踩过的坑是：短路触发后，剩下没审的人在工作台里还能看到这条单据，如果没做状态过滤，他们会重复处理。正确做法是短路后把剩余待办标记为已失效或自动跳过，具体看流程引擎的节点设置。另外，拒绝短路要慎用，1 人拒绝即拒绝在强合规场景下容易被质疑，建议至少两人拒绝才终止。

4.2 弃审逻辑与凭证纠错

审批流新增弃审逻辑：A 用户审核的单据只能 A 用户弃审。财务这边，凭证类型上增加参数“允许弃审他人审核的凭证”，为false时只能审核人弃审，为true时所有人都可弃审。这两个规则要一起看：审批流管单据，凭证类型管凭证，别以为改了审批流凭证就跟着变。

另一个高频需求是“业务系统生成的凭证可纠错”。V2.5 之前，外部凭证（业务系统生成）的纠错按钮是灰的，现在放开了。但放开不等于随便改，纠错会反向影响业务单据，操作前要确认凭证来源单据是否已结账。我一般要求客开在纠错入口加二次确认，并把纠错日志落到自定义表，出问题能追。

4.3 凭证打印按科目辅助核算段设规则

这是文档里写得最细的一块。原来只能按会计科目设打印规则（比如打印非零段），实际业务中科目有 A、B、C、D 四个辅助核算段，打印时只想显示 A、B 段。V2.5 的处理是：在账簿节点下增加打印规则设置画面，按账簿设置科目段的编码和名称打印规则——编码支持不打印、打印末级；名称支持不打印、打印首级、打印末级、打印首末级、打印全部级次。然后在账簿科目上设置该科目的打印规则，支持批量设置。凭证打印时取账簿科目的规则，账簿科目没设才取参数设置里的规则。

-- 排查凭证打印规则是否生效时，先确认账簿科目上有没有独立规则 -- 表名以实际环境为准，这里只示意查询思路 SELECT k.AccountCode, k.PrintRuleCode, k.PrintRuleName FROM GL_AccountBookSubject k WHERE k.AccountBookID = @bookId AND k.AccountCode = @subjectCode;

逻辑说明：这段查询不是产品自带脚本，是我排查时用来确认“账簿科目到底有没有挂规则”的思路。如果查出来PrintRuleCode为空，说明走的是参数设置里的全局规则，这时候打印结果和预期不符，就要么补账簿科目规则，要么改全局参数。参数上重点看“编码打印方式”和“名称打印级次”两个维度，它们组合起来决定最终输出，别只改一个就以为生效。

注意：文档里还提到一个连带问题——账簿科目同步会计科目时，没把“不符合设置的是否可制单”取消掉。如果后来把某个辅助核算段改成必输，已存在的科目该段为空却还能制单。V2.5 在会计科目批量维护里加了制单信息批量维护，凭证或交易分录使用科目时会弹框要求录入必输段。上线前建议跑一遍存量科目，把必输段为空的挑出来补。

5. 报表、个性化与档案下发：客开最常碰的三块

5.1 报表设计器的实体关联与 OQL 转 SQL

报表这块 V2.5 改动密集，对客开最有用的是两条。第一，报表数据源设计支持实体关联设计。以前只支持单实体 OQL，客开报表要在弱引用关联实体间取数（比如订单关联成本、应收关联总账）必须编程；现在多数可以直接用设计器配。第二，数据源设计器提供 OQL→SQL 对比，顾问可以借这个学 OQL 内部机制，在只能用 SQL 的场合（比如存储过程实现报表逻辑）先用设计器设计 OQL，再转成 SQL 拷进客开代码，还能看到实体对应的库名、字段名、表间关系和 OQL 默认的多语处理机制。

我的用法是：新报表先在设计器里把 OQL 配出来，用对比功能看它生成的 SQL，确认关联关系和过滤条件对不对，再决定是直接发布还是转 SQL 客开。这样比上来就写 SQL 稳，因为多语处理和权限过滤这些平台机制，手写 SQL 很容易漏。另外报表列显示权限也在这版支持了：设置实体属性权限，报表模板里定义报表列和实体属性的对应关系，设置了权限才生效，入口在 UBF 报表工具。

5.2 个性化配置的实用开关

个性化这版有几个能省时间的点。进入个性化编辑界面不用再点第二下，直接进；“重置模板”改名为“清除个人模板”；扩展出来的弹性域字段控件可以隐藏；任意节点 URL 加&personaldebug=EnableEditDebug都能进个性化设置。GRID 行数上限放开到 3000，查询方案最大显示行数放开到 10000，列表最大选择记录数可在系统级参数配置，默认 3000。

# 在任意节点 URL 末尾追加参数，直接进入个性化调试 # 原 URL 形如 .../Portal/UFSoft.UBF.UI.Portal.MainForm.aspx?lnk=xxx # 追加后： .../Portal/UFSoft.UBF.UI.Portal.MainForm.aspx?lnk=xxx&personaldebug=EnableEditDebug

逻辑说明：personaldebug=EnableEditDebug是个调试开关，加上后当前节点直接进个性化编辑态，省掉菜单里找入口的步骤。参数名大小写要一致，EnableEditDebug里 E 和 D 是大写。这个开关只影响当前会话的当前节点，不会改全局配置，所以可以放心在测试环境用。生产环境用之前确认权限，别让普通用户误进编辑态改了标准界面。

5.3 档案下发与依赖检查

基础设置这边，档案下发增加了依赖检查：所有下发参数对话框加“已下发检查”选项，勾选后下发时会检查当前实体对应的依赖项是否已下发，未下发则提示应先下发对应实体。料品列表还增加了“下发组织”过滤条件，客户、供应商上也加了，可以查未下发数据。

这块的血泪经验是：集团多组织环境下，下发顺序错了会导致下游组织拿到半套数据。比如料品没下发就下发 BOM，BOM 里的料品在下游组织找不到，报错信息还不一定指向根因。所以“已下发检查”建议默认勾上，宁可多一步提示，也别让脏数据流下去。供应商列表还支持显示最高预付比例并批量修改，查询条件里也能查，做采购集中管控时这个字段很实用。

6. 避坑清单：五个我实际踩过的 U9 V2.5 配置问题

6.1 界面缩放开了但某个界面没反应

现象：配置文件revise已设为true，大部分界面能缩放，个别单据不行。原因：该 Form 不在配置文件的列表里，或者pageuri和导航栏实际值不一致。解决：从导航栏 URL 的lnk=到&之间取值，按列表行格式补一行，重启 Portal 再试。别用肉眼抄 URL，复制粘贴最稳。

6.2 用户只输错一次密码就被锁定

现象：用户说只错了一次就被停用，活动按钮的勾没了。原因：错误次数是累计写库的，之前的历史错误没清零，累积到阈值这次刚好触发。解决：用有权限的账号登录，重新勾活动按钮；同时检查参数设置里的阈值是否过小，必要时重启 IIS 让计数状态刷新。长期看要把解锁流程写进运维手册。

6.3 审批短路后剩余待办还在工作台

现象：两人同意后流程已转下一活动，但剩下八个人的工作台里还能看到这条单据。原因：短路只终止了活动计算，没有清理剩余待办的状态。解决：在活动节点配置短路后的待办处理策略，把未处理记录标记为失效或自动跳过；如果标准功能不支持，用工作台的查询方案过滤掉已短路活动的单据。

6.4 凭证打印辅助核算段还是全打出来

现象：账簿科目上设了只打印 A、B 段，实际打印还是四个段都出来。原因：凭证打印取规则的顺序是先账簿科目、后参数设置，如果账簿科目规则没保存成功或科目编码对不上，就回落到全局规则。解决：按 4.3 的查询思路确认账簿科目上PrintRuleCode是否有值，没有就补设；批量设置后用一张测试凭证验证，别直接上生产批量打。

6.5 料品弹性域传到采购订单后值为空

现象：料品厂牌范围的弹性域配了传到采购订单，订单上字段是空的。原因：实体扩展字段的段数据来源界面需要配条件表达式，按业务要求配置取数条件和参数，弹性域属性类型检验的同时按规则赋值；只配了字段映射没配取数条件，传过去就是空。解决：在段数据来源界面补条件表达式，用一张有厂牌范围的料品做端到端测试，确认档案到单据的传值链路通了再推广。

7. 用 OQL 转 SQL 对比功能反推报表逻辑：我的验证习惯

报表客开最怕的不是写不出来，是写出来数字对不上还找不到原因。V2.5 的 OQL→SQL 对比功能我一般这么用：先在报表设计器里把目标报表的 OQL 配出来，不急着发布，点对比看生成的 SQL，重点核对三处——关联关系是不是走了弱引用实体的正确外键、多语处理有没有带语言过滤、权限过滤有没有按当前用户组织拼进去。这三处任何一处和手写 SQL 不一致，数字就会差。

举个具体场景：一张“订单关联成本”的报表，设计器里配 OQL 时选了订单实体和成本实体，关联字段是弱引用。对比出来的 SQL 里如果看到成本表带了语言条件而订单表没带，说明两个实体的多语属性配置不一致，这时候要么统一配置，要么在 OQL 里显式处理。确认 SQL 没问题后，如果必须用存储过程实现，就把这段 SQL 拷进客开代码，保留注释说明来源是哪个 OQL，后面维护的人能顺着找回来。

这套流程走下来，一张报表从设计到验证大概多花半小时，但能省掉后面反复对数的时间。我现在的习惯是：任何走 OQL 转 SQL 的客开报表，交付前必须把对比出来的 SQL 和执行结果截图存档，附在交付文档里。有一次客户半年后说报表数字变了，翻出当时的 SQL 一对比，是有人改了实体关联配置，十分钟定位。从那以后我每次做报表客开都强制走一遍 OQL 对比再落 SQL，不省这一步。希望帮到你。

本文还有配套的精品资源，点击获取