简介：用友U9 ERP V2.5手册面向企业信息化实施顾问、ERP运维人员及财务与供应链管理者，聚焦这款基于SOA架构的高端ERP产品在发版升级中的功能变化与整体能力梳理。资源包内仅含1个docx文档，体积约9.54MB，以文字说明形式系统呈现产品概述、关键应用特性与关键技术特性，便于按章节检索与对照阅读。内容覆盖财务、人力资源、制造、供应链、项目制造、成本、质量、协同门户及UAP平台等领域的增量说明，并围绕多组织协同、业务灵活性、全球化管理展开，涉及多工厂制造协同、多账簿多币种核算、集中采购与跨组织调拨、项目全生命周期成本等具体场景，同时阐述完全SOA架构下的ESB、BPM、企业搜索与Office集成等技术要点。已有345人学习，适合需要理解U9 V2.5版本定位、评估升级影响或梳理模块边界的技术与业务人员参考。
1. 多组织 ERP 的“实时”到底实时在哪：从一份发版说明看 U9 的架构底牌
很多 ERP 手册读起来像功能清单，翻完只记得“支持多组织、多币种、多账簿”几个词，却说不清它凭什么能在一个集团几十家法人、上百个工厂之间做到“实时”。这份 V2.5 发版说明里藏着一个反直觉的结论：U9 的“实时企业”不是靠数据库同步快，而是靠一套完全 SOA 的服务装配机制，把业务动作、信息反馈、绩效监控、市场响应串成同一条事件链。换句话说，实时是架构设计出来的，不是性能调优调出来的。搞懂这条链怎么搭、服务怎么插进总线、审批怎么短路、报表怎么跨实体取数，你才能明白为什么一套 2012 年的产品文档，今天读起来仍然有底层参考价值。
1.1 从“局部 SOA”到“完全 SOA”：差别不在名词，在装配粒度
发版说明里反复强调一个定位：这是“全球第一款面向完全 SOA 和实时企业的解决方案”，并且特意对比了“局部采用 SOA”。这个对比不是营销话术，它指向一个很具体的工程差异——服务组件的装配粒度到底落在哪一层。
局部 SOA 的典型做法是：核心单体系统不动，只在边界上包一层 Web Service，对外暴露几个接口。这种架构里，服务是“贴”上去的，业务流程一变，还是得改单体代码。而完全 SOA 的做法是把业务能力本身拆成服务组件，通过企业服务总线（ESB）动态插入、通过 Portal 发布给用户。文档里那句“可以灵活地将新的服务组件‘插入’ESB 中，并通过 Portal 更新发布到用户”，说的就是装配发生在运行期而不是编译期。
这个差别带来的直接后果是：多组织场景下，同一个“采购收货”动作，在不同法人、不同工厂可能要走不同的审批链、不同的成本核算规则、不同的凭证模板。如果服务是贴上去的，你得为每种组合写分支；如果服务是可装配的，你换的是组件配置而不是代码。我一般会这么理解：局部 SOA 是给老房子加装电梯，完全 SOA 是盖房子时就把电梯井预留好。
文档还提到 UAP 平台支撑“基于特征模型库的服务组件管理、定制、装配、部署和升级”。特征模型库这个词很关键——它意味着组件的可变部分被抽成了特征，定制不是改源码，而是选特征。这是“按需应用”能落地的前提，也是后面所有多组织、多账簿、多币种能力能共存而不互相打架的根。
1.2 “实时”的四个层次：业务处理、信息反馈、绩效监控、市场响应
文档把实时企业拆成四件事：实时业务处理、实时信息反馈、实时绩效监控、实时市场响应。这四层不是并列的口号，而是一条有依赖顺序的链。
最底层是实时业务处理，对应的是“以业务为基础触发整个研发、生产、采购、物流、分销、财务的同步”。注意这里的动词是“触发”和“同步”，不是“事后汇总”。传统 ERP 里，生产完工单和财务成本是两套节奏，月底才对齐；U9 的设计意图是业务动作发生即产生下游事件。
第二层实时信息反馈，靠的是企业搜索和报表的实时钻取。文档里说企业搜索“提供实时性访问，支持结构化、非结构化信息融合”，报表“可任意向下钻取”。这两条合起来的意思是：信息不是等 ETL 跑完才可见，而是查询时直接打到业务实体上。
第三层实时绩效监控，落在预警和消息通道上。文档里 CBO 那节有个很具体的例子：成本计算结束后，通过请求执行结果事件触发消息通知，规则条件写成StartsWith(DailyPattern.Request.Code,"R-CBO4CRM") and DailyPattern.IsSucceeded==false。这就是把“绩效监控”做成了事件订阅，而不是等人去翻请求监控。
第四层实时市场响应，对应的是渠道管理、客户门户、供应商门户这些跨组织协同能力。四层叠起来，才构成文档说的“全球商务”四个协同：业务、信息、资源、市场。
提示：读这类架构文档时，把“实时”当成一个需要逐层兑现的承诺，而不是一个形容词。每一层实时背后都得有具体的机制支撑，缺一层，上面那层就是空的。
1.3 为什么值得搞懂：多组织协同的复杂度是乘法不是加法
多组织 ERP 的难点，外行容易低估。三个法人、两个工厂、两种会计制度，复杂度不是 3+2+2，而是要考虑组织间交易、内部供应链、跨组织领料调拨、多账簿并行核算这些交叉场景。文档里供应链那节列了“集中接单分散生产、跨组织接单出货”“集中采购，实现集中收货或分散收货或集中代购”“跨组织的领料与调拨”，每一条都是组织间的一笔账，而且这笔账在财务侧还要按多账簿、多币种分别落。
如果架构不支持组织维度的原生建模，这些场景只能靠二次开发硬拼，拼出来的系统每加一个组织就多一堆特判。U9 把多组织做进平台层，业务组件天然带组织上下文，这才是“多组织协同”作为客户价值第一条的底气。搞懂这套组织上下文怎么在服务调用链里传递、怎么在权限和数据过滤里生效，比记住它支持几个组织有用得多。后面几章就沿着这条链，从审批流的短路算法、报表的 OQL 跨实体取数、到组织权限复制和档案下发的依赖检查，一层层拆开看它到底怎么实现的。
2. 审批流的短路算法：为什么两个人同意就能跳过剩下八个人
审批流是 ERP 里最容易被当成“配置项”的功能，但它内部藏着一个相当讲究的算法设计。文档里那条“审批结果的短路算法”值得单独拎出来讲，因为它把“流程正确性”和“响应实时性”这对矛盾摆到了台面上，并且给出了一个明确的取舍。
2.1 旧逻辑的痛点：等齐十个人才算一次审批
文档给的案例很干净：活动 A 需要 10 个人审核，规则是其中 2 人同意则同意、1 人拒绝则拒绝。旧逻辑要等 10 个人全部处理完成，才能计算结果转到下一活动。新逻辑是其中两人同意就立即转到下一活动。
这个差别在单据审批上不明显，但在批量场景下是灾难性的。想象一个采购订单要过十人会签，前两个人五分钟内就点了同意，剩下八个人可能分布在不同的时区、不同的工厂，有人出差三天没登系统。旧逻辑下这张单子就卡在活动 A 上，下游的收货、入库、付款全部排队。这就是“实时业务处理”在审批环节的翻车现场——流程引擎本身成了瓶颈。
短路算法的本质是把“会签”从“全量收集后计算”改成“增量判定后提前收敛”。它需要引擎在每次审批动作后重新评估当前活动的判定条件，一旦条件满足（同意数达到阈值或拒绝数达到阈值），立即触发状态迁移，并把剩余待办标记为失效或跳过。
2.2 短路判定的实现思路：增量计数与阈值收敛
常见的实现思路是给每个审批活动维护一组计数器，而不是每次全表扫描审批记录。下面这段伪代码按这个思路写，重点看判定时机和剩余待办的处理：
# 审批活动短路判定（示意实现，非产品源码） class ApprovalActivity: def __init__(self, total, approve_threshold, reject_threshold): self.total = total # 应审人数 self.approve_threshold = approve_threshold # 同意阈值，如 2 self.reject_threshold = reject_threshold # 拒绝阈值，如 1 self.approve_count = 0 self.reject_count = 0 self.finished = False def on_approve(self, voter): if self.finished: return "already_closed" # 短路后到达的审批直接忽略 self.approve_count += 1 # 关键：每次动作后立即判定，而不是等 total 到齐 if self.approve_count >= self.approve_threshold: self.finished = True return "pass_and_skip_rest" # 通过，剩余待办作废 return "pending" def on_reject(self, voter): if self.finished: return "already_closed" self.reject_count += 1 if self.reject_count >= self.reject_threshold: self.finished = True return "reject_and_skip_rest" # 拒绝，剩余待办作废 return "pending"这段代码里有两个设计点值得说。第一，finished标志位是幂等保护，短路发生后迟到的审批动作必须被识别为“已关闭”，否则会出现流程已经流转、又被人补审一次的脏数据。第二，判定放在每次动作之后而不是定时轮询，这是“实时”在流程引擎里的具体兑现方式——事件驱动而非批处理。
参数上，approve_threshold和reject_threshold是活动级配置，不同活动可以不同。文档案例里同意阈值 2、拒绝阈值 1，意味着这是一个“宽进严出”的会签：凑够两个支持就放行，但只要有一个人反对就否决。这种配置适合风险偏好保守但效率要求高的场景，比如大额付款审批。
2.3 收回、退回意见与弃审：审批状态机的三个边界
短路算法解决的是“正向流转快”，但审批流还有三个反向边界，文档里分别给了机制。
收回：提交人在第一个审核人未审核之前，可以收回提交的单据。这是一个时间窗口约束，实现上要在提交时记录“当前活动是否已有审批动作”，收回操作前先校验这个标志。窗口一旦关闭，收回按钮就该失效，否则会出现单据已经被审了一半又被提交人抽走的情况。
退回意见：以前退回后用户看不到上级为什么退回，现在可以显示。这看似是个 UI 改进，底层是退回动作要携带意见数据并持久化到审批历史里，而不是只改状态。没有这条，退回就是黑匣子，用户只能猜。
弃审：A 用户审核的单据，只能 A 用户弃审。这条在财务凭证那节还有更细的版本——凭证类型上增加参数“允许弃审他人审核的凭证”，为 false 时只能审核人弃审，为 true 时所有人都可弃审。这是一个典型的“默认严格、按需放开”的设计，把权限粒度下沉到单据类型而不是全局开关。
注意：短路算法和弃审逻辑放在一起看会发现一个隐患——短路后剩余待办被作废，如果此时有人对已通过的审批做弃审，活动状态要不要回滚？常见的实现是把弃审视为一次新的状态迁移，重新打开活动并重置计数器，而不是简单地把 finished 置回 false。这一点在配置复杂会签时要特别验证。
2.4 批量审核工作台：把散落的待办收成一个入口
文档提到批量审核工作台把所有需要审核的单据类型集成到一个页面，入口在 Portal 主菜单最右侧，支持设置审核动作、意见等。这个功能的价值不在 UI，在于它把“审批”从“逐个单据点进去”变成了“按类型聚合处理”。
从机制上看，工作台需要跨单据类型做统一的任务查询，这要求审批任务表有统一的类型标识和统一的动作接口。如果每种单据的审批各写一套，工作台就聚合不起来。这也解释了为什么文档强调“所有的人工（单人、多人）节点均能设置消息模板”——统一的消息模板机制和统一的任务模型是同一套抽象的两个面。
消息模板那节还提到支持 TPL 语法定义复杂模板，能实现循环、判断。这意味着通知内容不是简单字符串拼接，而是有一个小的模板引擎在跑。对于多组织场景，同一个审批节点在不同组织下可能要展示不同的字段组合，模板引擎的存在让这件事不用改代码。
3. 报表与打印的 OQL 机制：跨实体取数为什么不再必须写代码
报表是 ERP 里客开量最大的地方，也是最容易变成“每个客户一套存储过程”的地方。V2.5 在报表数据源设计上做了几件事，合起来看是一条清晰的主线：把原来必须编程实现的取数逻辑，下沉到声明式的 OQL 层。
3.1 OQL 到 SQL 的映射：一个可学习的中间层
文档里有一条很容易被忽略但信息量很大的功能：报表数据源设计器提供 OQL 到 SQL 的对比功能，顾问可以通过它学习 OQL 内部机制，在只能用 SQL 实现的场合先设计 OQL 再转成 SQL 拷贝到客开代码里，还能查到实体对应的数据库名、字段名、表间关系，以及 OQL 默认的多语处理机制。
这条功能暴露了 U9 报表层的真实结构：OQL 不是 SQL 的简单包装，它至少承担了三件事——实体到表的映射、表间关系的解析、多语字段的处理。多语处理尤其关键，一个料品名称在数据库里可能是多行多语记录，OQL 层要把它折叠成用户看到的一个字段。如果直接写 SQL，这个折叠逻辑得自己实现，写错就是报表里出现重复行或者语言错乱。
我一般会这么理解 OQL 的定位：它是业务实体层的查询语言，SQL 是存储层的查询语言，两者之间隔着一层语义映射。这层映射的存在，让“订单关联成本、应收关联总账”这类弱引用关联实体的取数不用再写代码——设计器里声明关联关系，OQL 负责翻译成 JOIN。
3.2 弱引用关联的取数：为什么订单能直接关联成本
文档明确说，之前报表数据源只支持单实体 OQL 设计，实际客开报表多数需要在弱引用关联实体间关联取数，比如订单关联成本、应收关联总账，之前必须编程实现，现在设计器可直接设计。
弱引用这个词在文档里出现过两次，另一次是料品生产页签增加成本要素字段时说的：“由于成本要素在 MFG 中，料品在 PUB 中，为了防止逆向引用采用弱引用的方式”。这两处合起来说明了弱引用的设计动机：跨模块的实体不能强引用，否则模块间产生编译期依赖，PUB 模块会被 MFG 拖住。弱引用用 ID 关联代替对象引用，解耦了模块，但代价是查询时不能靠对象导航，必须显式声明关联。
报表设计器支持弱引用关联，本质上是把这层显式声明做成了可视化配置。用户在界面上指定“订单的成本字段关联成本实体的某字段”，设计器生成对应的 OQL 关联子句。这降低了门槛，但也埋了一个坑：弱引用关联没有数据库外键约束，关联字段类型不匹配或者脏数据会导致报表结果异常，排查时得回到数据本身看。
3.3 报表列权限与打印模板授权：权限要落到列和模板两级
文档里报表列显示权限支持这条，机制上分两步：先设置实体属性权限，再在报表模板中定义报表列同实体属性的对应关系，设置了权限才生效。这个两步设计的原因是报表列名和实体属性名不是天然对应的——一个报表列可能是公式列、可能是多语字段的某个语言版本，必须显式建立映射，权限校验才知道该查哪个属性。
打印模板授权则从“只能按组织授权”扩展到“按组织、角色、用户授权”，入口在 UBF 打印个性化设置里右键进入。这个扩展的意义在于：同一个打印模板，不同角色看到的可能是不同版本（比如金额字段对某些角色隐藏），授权粒度下沉到用户级才能支撑这种场景。
3.4 打印细节里的工程取舍：PDF 书签、表尾缩放与 CSV 税控兼容
打印这块有几个小功能，单看是体验优化，合起来能看出设计者对“打印是业务闭环最后一公里”的理解。
PDF 书签打印支持，输出时在 PDF 左侧用单号标识每页主要内容，点击书签跳转。这对多页单据（比如几百行的发货单）是刚需，实现上是在生成 PDF 时写入大纲节点，节点标题取单据关键字段。
表尾单元格缩放，之前只在 Table 明细行有效，现在表尾文本框也支持自动缩放。这是个典型的“功能覆盖不全”修补——明细行和表尾走的是不同的渲染路径，缩放逻辑得分别接。
CSV 格式输出兼容税控机格式，这条背后是发票打印的合规要求，CSV 的字段顺序、编码、分隔符都得按税控机的约定来，不能按通用 CSV 处理。
报表打印支持水印输出，通过背景图片设计实现，需要更新 UBF 开发工具。水印在财务单据上是防伪和状态标识的常见需求，用背景图而不是叠加文字层，说明渲染管线支持图层合成。
报表打印设计器支持撤销/恢复，这是设计器从“能用”到“好用”的分水岭，实现上要有命令栈记录每次格式变更。
电子表格打印支持，解决的是表头大固定表格要靠文本框拼、效率低的问题，设计器增加固定表格设计功能。这条和上一条撤销恢复放在一起看，说明这一版在报表设计器的人机工程上投入不小。
4. 组织、权限与档案下发：多组织数据的同步与隔离怎么平衡
多组织 ERP 最拧巴的地方在于：数据既要共享又要隔离。料品档案集团统一维护，但各工厂可能要本地扩展；权限既要能批量复制，又要能按角色动态更新；档案下发既要快，又要防止依赖缺失导致下游报错。这一章拆这三组矛盾。
4.1 档案下发的依赖检查：为什么下发前要先查依赖
文档里“档案下发增加依赖检查”这条说得很直白：所有下发参数对话框增加“已下发检查”选项，选择后下发时会检查当前实体对应的依赖项是否已下发，未下发则提示对应实体应该先下发。
这个机制解决的是一个血泪经验型问题：料品下发到某组织，但料品引用的计量单位、分类、厂牌没下发，下游组织拿到料品后一用就报错，而且报错信息往往指向一个不存在的引用，排查半天才发现是依赖缺失。依赖检查把这个问题前置到下发动作，用一次额外的查询换掉下游的一堆脏数据。
实现上，每个可下发实体要维护一张依赖关系表，记录它引用了哪些实体。下发时按依赖图做拓扑检查，有环或者有缺失就阻断。这里有个细节：依赖检查是可选的（“如果选择则检查”），说明设计者考虑了性能——大批量下发时逐个查依赖会慢，给用户留了跳过检查的口子。但跳过就意味着自己承担风险，这是个明确的取舍。
料品列表还增加了“下发组织”作为自定义查询方案的过滤条件，用户可以查未下发数据。这条和依赖检查是一对：一个防错，一个让用户能主动发现漏网之鱼。客户、供应商上也加了同样条件，说明下发机制是跨实体统一的。
4.2 角色动态视图权限的自动更新：从三步操作到一步
文档里这条的原始痛点写得很具体：一个动态视图被很多角色引用，更新视图的原逻辑是先在角色上删除该视图、再修改视图、再重新对应角色加上新视图，视图被多个角色关联时工作量巨大。改为直接修改动态视图，引用该视图的角色的数据权限随之更新。
这是一个典型的“引用关系反向传播”问题。动态视图和角色是多对多关系，修改视图内容后，所有引用它的角色的权限缓存都要失效重建。旧逻辑把这件事推给用户手工做，新逻辑在视图保存时触发传播。
实现上要注意两点。第一是传播的时机：是保存即传播还是定时传播？保存即传播实时性好，但视图被几十个角色引用时保存会卡；定时传播则有一段时间的权限不一致。文档没说具体选哪种，但从“随之更新”的措辞看，倾向保存即传播。第二是传播的范围：只更新数据权限条件，还是连菜单、功能权限一起刷新？从上下文看是数据权限条件同步，因为动态视图定义的就是数据过滤条件。
注意：动态视图自动更新后，如果某个角色原本依赖旧视图条件做了额外的权限微调，更新可能覆盖这些微调。上线这类变更前，建议先导出各角色的权限配置做比对，别等用户反馈“怎么突然看不到某些单据了”才回头查。
4.3 跨组织权限复制：复制的不只是菜单
文档说平台跨组织权限复制功能增强：角色之间权限可复制，用户权限可以复制，是否菜单、数据、功能、字段都可以复制。这句话的重点在最后半句——权限有四个维度，复制时要能选择复制哪些维度。
菜单权限是“能不能看到入口”，功能权限是“能不能点按钮”，数据权限是“能看到哪些行”，字段权限是“能看到哪些列”。四个维度的存储结构不同，复制逻辑也不同。如果只复制菜单，用户进去发现按钮全灰；如果只复制功能不复制数据，用户能看到所有组织的数据，这是越权。所以复制功能必须让用户显式选择维度，而不是一把梭。
用户组织角色分配增加 Excel 导出功能，这条和权限复制是一套组合拳：先导出看清现状，再决定复制什么。导出的是用户-组织-角色-权限的展开表，方便做差异比对。
4.4 料品厂牌与弹性域传值：扩展字段怎么跨档案和单据流动
文档里料品厂牌相关的几条值得连起来看：厂牌界面支持个性化、厂牌支持多选参照、物料厂牌范围扩展字段在后续业务显示、弹性域在档案和单据之间传值。
多选参照这条的实现细节是：新建厂牌多选参照，修改厂牌料品交叉表可以从多选参照中返回创建多条记录。这意味着参照控件返回的是集合而不是单值，交叉表要支持批量插入。这类功能看着小，但涉及参照控件、交叉表、事务边界三处配合，任何一处按单值处理都会翻车。
弹性域传值那条更关键：客户要求厂牌范围的弹性域传递到采购订单上，实体扩展字段的段数据来源界面增加条件表达式，用户按业务要求配置取数条件和参数，然后在弹性域属性类型检验的同时按规则赋值。这是一个“配置驱动的字段映射”机制——不是硬编码“厂牌弹性域传到采购订单某字段”，而是让用户声明取数条件和赋值规则。灵活性的代价是配置错了很难查，因为赋值发生在运行时，报错信息可能只告诉你“类型检验失败”，不告诉你哪条规则导致的。
5. 避坑与排查：这些机制用错时的典型翻车现场
前面几章讲的是机制怎么设计，这一章讲机制用错时怎么表现、为什么、怎么解。都是配置和运维层面能复现的问题，按“现象 → 原因 → 解决”写。
5.1 登录锁定：只输错一次就被停用
现象：用户反馈只输错一次密码，账号就被锁定，活动按钮的勾被去掉了。
原因：文档里写得很清楚，错误次数是累计形式，每错误一次即向数据库写入，累积到一定次数时停用。也就是说计数不是按会话清零的，而是跨会话累计。用户可能之前在别的终端输错过几次，自己忘了，这次再错一次正好触顶。另外文档还提示“需重启 IIS”，说明锁定状态和会话缓存有关，不重启可能状态不一致。
解决：用别的用户登录，重新勾选活动按钮即可重新启用。要根治，去系统管理参数设置里调整允许的错误次数，并确认计数是否需要定期清理。重启 IIS 这一步别省，否则可能出现“已经重新启用但用户还是登不上”的玄学现象。
5.2 界面缩放不生效：配置文件开了但没加 Form
现象：按文档把UFSoft.UBF.UI.ReviseLayout.Config的 revise 属性改成 true，部分界面能缩放，部分还是不行。
原因：文档明确说“此功能不是对所有界面都有效”，配置文件里描述了所有可以缩放的 Form 列表，不在列表里的 Form 不会生效。开关只是总闸，具体 Form 还得在列表里。
解决：从 IE 导航栏取 pageuri——每进一个节点，URL 中lnk=后直到&之前的内容就是 pageuri，按列表行格式自行添加。加完刷新缓存再验证。这里容易踩的坑是 pageuri 取错，把查询参数也带进去了，导致匹配不上。
5.3 交易分录生成时提示“科目某段不允许为空”
现象：某项目升级后，生成交易分录时报“科目 XXX 的某某段不允许为空”，但科目模板看着没问题。
原因：文档在账簿科目那节给了排查顺序——先检查会计科目模板是否设置了段取值规则，再检查账簿科目上该段是不是必输。深层原因是这一版放开了“已存在会计科目在使用时只按是否制单控制”的限制，后修改某个辅助核算段为必输时，已存在的科目该段为空，系统开始拦截。这是行为变更，不是 bug。
解决：按文档给的两步查。如果是模板段取值规则问题，改模板；如果是账簿科目必输设置问题，用会计科目批量维护里的制单信息批量调整，或者对存量科目补录辅助核算段。复制原凭证或由会计科目生成时也会走这个校验，所以补数据要覆盖所有生成路径。
5.4 报表 OQL 扩展只显示第一行
现象：报表打印的 OQL 扩展查询，明明查到多条，输出只有第一行。
原因：这是旧行为，文档说之前只显示第一行，现在显示全部。如果升级后仍然只显示一行，大概率是 OQL 语句里还留着Top 1限定，或者模板没跟着升级。
解决：检查 OQL 语句，需要全部内容就去掉Top 1；确实只需要第一行的，保留限定并在模板注释里写清楚，避免后人误改。这类“行为默认值变了”的变更，升级清单里要单独标出来。
5.5 凭证打印辅助核算段打多了或打少了
现象：凭证打印时，某个科目有 A、B、C、D 四个辅助核算段，但只想打印 A、B 段，打出来却是全部或者全空。
原因：旧产品只能按会计科目设置打印规则（比如打印非零段），无法按辅助核算段精细控制。这一版新增了按账簿设置科目段打印规则，但规则有优先级：凭证打印时取会计科目对应的账簿科目打印规则，账簿科目未设置才取参数设置中的规则。规则没配对，就会落到默认行为。
解决：先在账簿节点下的打印规则设置画面配好编码和名称的打印方式（编码支持不打印、打印末级；名称支持不打印、打印首级、打印末级、打印首末级、打印全部级次），再在账簿科目上引用规则，可卡片参照也可列表批量设置。配完拿一张多段科目的凭证验证，别只看单段科目。
6. 从“完全 SOA”到“按需应用”：这套架构的取舍与验证方法
把这份发版说明从头读到尾，会发现它所有的功能点都指向同一个设计哲学：把可变性从代码里抽出来，放到配置、模板、特征模型和装配层。审批短路是把判定条件从流程定义里抽出来做成阈值参数，报表 OQL 是把取数逻辑从存储过程里抽出来做成声明式查询，档案下发依赖检查是把数据完整性从下游报错里抽出来做成前置校验，动态视图自动更新是把权限传播从手工操作里抽出来做成引用反向刷新。每一条单独看是功能，合起来是一套“降低变更成本”的架构。
这套架构的代价也很明确。第一是配置复杂度上移：原来写代码的人现在要配模板、配规则、配依赖，配错了排查链路更长，因为错误发生在运行时而不是编译时。第二是性能换灵活性：依赖检查、动态视图传播、OQL 多语折叠，每一项都在查询或保存路径上加了开销，文档里那些“默认关闭”“可选检查”“上限放开到 3000/10000”的参数，本质都是在灵活性和性能之间留调节旋钮。第三是升级兼容：行为默认值变更（比如 OQL 扩展从只显示第一行改成显示全部、科目段必输校验变严）会让老项目升级后突然报错，这类变更必须有清单和回归用例。
如果要验证一套多组织 ERP 是否真的做到了“完全 SOA”，我一般会看三个可操作的信号。一是看服务组件能不能在不改代码的前提下重新装配并发布到 Portal，而不是只能重启生效。二是看跨实体报表能不能纯配置出来，尤其是弱引用关联的取数，如果需要写存储过程才能出数，说明抽象层没兜住。三是看权限变更的传播是不是自动的，改一个动态视图要手工去几十个角色上重挂，那多组织协同就是纸面上的。
从那以后我每次评估这类平台，都会先挑一个跨组织的端到端场景——比如集中接单、分散生产、跨组织领料、多账簿核算——从头走一遍，看哪一步需要写代码、哪一步需要手工补数据、哪一步报错信息说不清原因。这三类步骤的数量，基本就决定了这套系统上线后的运维成本。希望这份拆解帮到你，下次翻功能清单时能多问一句“这背后是哪层机制在撑”。
本文还有配套的精品资源，点击获取
