1. 报错本质：你踩中的不是SQL问题，是NC的权限模型
做用友NC报表的兄弟，十有八九都见过这句话：“查询数据出错，用户没有组织权限”。第一次遇到，我差点把报表的SQL翻了底朝天，又是看表关联又是查过滤条件，折腾半天才发现问题根本不在SQL，而是NC这套老牌ERP的权限体系在卡你。
先说结论：这条报错的直接触发点，是自由报表在执行查询时，系统会校验当前操作员的组织数据权限。如果用户在某个业务组织下没有可见权限，或者权限规则没配置好，系统就直接把报表请求拦下来，抛出了那句让你摸不着头脑的话。它本质上不是一个“报表问题”，而是一个“权限问题”。
NC里，组织和权限是绑定的。一个用户能不能看到某个组织的数据，取决于几层判断：有没有分配“组织”相关的数据权限、当前登录的组织是否正确、报表节点本身有没有分配给人。这条路只要有一环断了，就会报这个错。而且NC的口径比较死板——它给操作员的提示不会具体到“哪个组织没权限”，只会给你一个笼统的“用户没有组织权限”。这也是为什么很多人排查半天找不出原因。
我后面会细拆，先记住大方向：遇到这条报错，优先查权限，其次查缓存，最后才是查SQL。顺序反了，效率会差很多。
2. 权限体系速览：报表查询到底在“验证”什么
要解决这个问题，你得先搞清楚自由报表在查询时，系统内部到底做了哪些校验。它不是你想的那样“用户点了查询，系统就老老实实跑SQL”，而是在跑SQL之前和之后，都套了一层权限过滤。
2.1 数据权限：组织过滤的“总开关”
NC对报表数据默认做组织级隔离。也就是说，一个集团里的不同公司，彼此的业务数据默认不可见。自由报表里的数据源，如果取自业务单据或业务表（比如销售订单、采购入库单这类），每一行数据都带着“组织”字段。
系统在执行报表查询前，会解析当前操作员拥有哪些组织的查看权限。这个权限不是自动继承的，它由管理员在“数据权限”节点里单独配置。常见的配置方式是给某个用户或角色分配“职责-组织”的对应关系。如果这个关系没配，或者配错了组织，你看到的报表数据就可能为空，严重一点直接报错。
2.2 功能权限：报表和菜单的“分配关系”
除了数据层的组织权限，NC里还有个功能权限的概念。自由报表在开发完成后，需要在“动态建模平台-报表平台-自由报表”里把报表分配给指定的用户或角色。这一步被很多人忽视——报表做完了，自己测试的时候用管理员账号能跑通，但换一个普通业务账号就报错。
原因很可能就是：报表资源没有分配出去。普通账号根本没有访问该报表节点的权限，系统在权限判定阶段就直接拒绝了。这种场景下，报错信息和“组织权限”是一致的，都是同一套权限框架在起作用。
2.3 组织参数：报表SQL里的“隐含条件”
还有一个容易踩的坑：自由报表的数据源SQL里，往往写了类似pk_org = #{org}或pk_group = #{group}这样的隐含条件。这些参数取自报表查询界面上的“组织”字段，系统会自动把当前登录组织或用户选择的组织传给报表SQL。
如果你的SQL里写了组织参数，而用户在界面上没有正确选择组织，或者默认组织设置得不对，也会触发类似的权限拦截或查出空数据。很多开发者总觉得“我在数据库里直接查这些表是没问题的”，但到了NC的报表语境里，表还是那张表，查询逻辑却被权限框架裹了一层。
2.4 会话和缓存：老ERP的“隐形坑”
NC是老牌Java架构的ERP，登录态和权限信息存在会话里，还会经过缓存。管理员刚改了权限配置，同一个会话可能还持有着旧的权限缓存。于是就会出现一个非常气人的现象：权限明明已经分配好了，用户重新登录了还是报同样的错。
这种情况我在项目里见过太多次了。排查了半天，权限配置干净利落，最后发现是会话缓存没刷新。解决了这个，报错可能立马消失。
3. 定位问题：三步排查法，快速找到卡点
讲完原理，下面说说实际操作。遇到“查询数据出错，用户没有组织权限”，别慌，按下面三步走，通常能在十分钟内定位到问题。
3.1 第一步：用超级管理员账号复现
这是最重要的第一步。用超级管理员或系统管理员账号，同一张报表、同一个查询条件，再查一次。如果管理员也报错，说明问题出在权限配置层面，或者报表SQL有问题，和具体业务用户无关。
如果管理员能正常查询，而普通用户报错，那就要对比一下两者的权限差异。不要一上来就改SQL，那样大概率是白忙活。
3.2 第二步：核对用户职责范围
用管理员账号进入“系统管理-权限管理-用户管理”，找到报错的用户，查看它的可用组织范围。重点看两个地方：
- “所属组织”里是否包含了报表数据对应的业务组织；
- 该用户是否拥有“自由报表”节点的功能权限。
很多时候，用户在A公司，但报表数据挂在B公司，或者用户定位在“集团”层级但报表取数按“公司”过滤，这些都会导致权限对不上。用人话说就是：用户虽然在系统里活着，但系统不认为他有资格看其他公司的数据。
3.3 第三步：看数据权限规则
这个步骤很关键，也最容易被遗漏。进入“数据权限”节点，查看该用户或对应角色，是否配置了针对“组织”维度的数据权限规则。没有配置的，补齐配置；配置了但范围不对的，调整范围。
配置完成后，记得做一次“用户退出-重新登录”的动作，或者让用户在浏览器里清掉会话缓存再登录。这一步能规避大部分缓存问题。
3.4 排查顺序速查表
| 排查项 | 操作入口 | 关注点 |
|---|---|---|
| 功能权限 | 报表节点权限分配 | 报表是否分配给用户/角色 |
| 数据权限 | 数据权限节点 | 组织维度规则是否覆盖目标组织 |
| 用户组织 | 用户管理 | 所属组织和默认组织是否正确 |
| 报表参数 | 自由报表设计器 | 数据源SQL和取数参数是否匹配 |
| 会话缓存 | 用户重新登录 | 权限配置后是否强制刷新会话 |
提示：排查时按表格从上往下走，绝大多数问题出在前两行。
4. 典型案例：我在项目里遇到过的四种场景
光讲方法不给案例，等于纸上谈兵。下面这四种场景，是我在多个NC项目里真实遇到过的，每一种都对应着不同的排查路径。对照你自己的情况，大概率能找到影子。
4.1 场景一：报表做完了，没分配出去
这是最“冤”的一种情况。当时客户方的财务总监要一张应收账龄报表，我们做好了测试没问题，上线后财务主管一登录就报“用户没有组织权限”。一开始我们也怀疑是组织和数据权限的问题，折腾了半天。
最后打开“自由报表”节点列表一看，报表本身根本没分配给财务主管的角色。原因是我们在开发环境用的是管理员建表，管理员天然有全部权限，可普通用户没被分配这个节点资源。用一句话概括就是：开发环境跑通了，不等于生产环境能用。分配路径是“用户管理-角色-功能权限-报表平台-自由报表”，勾选对应报表保存即可。
4.2 场景二：用户能看到菜单，但看不到数据
另一种常见情况是：用户能点进“自由报表”菜单，列表能显示，但一点查询就报错。这种情况基本可以确定数据权限没配置到位。
我在一个项目里遇到过：客户给操作员分配了某分子公司的“查询”职责，但数据权限规则里只配了“本人数据”，没有配“组织数据”。结果操作员查不到该公司名下的报表数据，系统干脆报了“无组织权限”的错。解决方法就是在数据权限规则里，把组织维度的访问范围改成“下级组织”或“当前组织及下级”，保存后重新登录。
4.3 场景三：集团和公司层级错位
集团型客户常会遇到跨组织查询的需求。比如集团财务想看所有子公司的报表数据，但如果用户的职责范围只在集团本级，数据权限却没有向下延伸到子公司，那报表一样会报权限错误。
这种场景的典型特征是：管理员账号查询一切正常，普通用户查询就不行，而且换哪个子公司都报错。排查方法是检查该用户的“职责-组织”范围，确认是否勾选了“包含下级组织”。如果没勾，补上；如果系统不支持跨多组织查询，那就要考虑在报表数据源SQL里按“集团”维度取数。
4.4 场景四：权限配置没问题，但缓存害人
还有一种情况最无语：所有权限都检查过了，配置也正确，但用户就是持续报错。重启服务、清理缓存、重新登录都试过，最后发现是NC的系统缓存没有刷新。
NC的权限数据会缓存到服务器内存中，管理员在后台改了权限配置，普通用户的会话不一定会立刻生效。解决方案有两种：一是让用户退出重新登录，强制刷新会话；二是在“系统监视器”节点里清掉缓存，或者用“系统管理员”账号执行“清除缓存”操作。实操下来，第二种方式更有效，尤其是集团大并发环境。
5. 从根源解决：权限规则的配置细节与踩坑经验
很多朋友遇到这个问题，网上搜了一圈，最后不了了之。原因是大家只知道了要查权限，但配置权限这一步，本身就藏了很多细节。下面我把实际操作中总结的配置要点和避坑经验分享出来。
5.1 明确“分配的粒度”——按用户还是按角色
NC支持两种权限分配粒度：直接分配给用户，或者分配给角色后把角色挂给用户。建议优先按角色分配。原因很简单：用户数量大，角色数量少，角色分配便于后期维护。
一个项目的权限设计如果做得好，应该是“角色-职责-组织”三层结构。自由报表的分配对象建议挂在角色上，数据权限也挂在角色对应的职责上。这样一个人换岗，只要换角色，权限全部跟着变。如果直接分配给用户，换岗就要一个个改，后期全是坑。
5.2 数据权限的“规则类型”怎么选
NC数据权限节点里，组织维度的规则一般分三种类型：
- 仅本人：只能看到当前登录人自己的数据；
- 本组织：能看到当前登录组织的全部数据；
- 本组织及下级：能看到当前组织及其所有下级组织的数据。
选哪种，取决于业务场景。集团财务要看全集团，就选“本组织及下级”；分子公司只能看自己，就选“本组织”；如果要求只能看自己负责的单据，才选“仅本人”。默认情况下，自由报表取数建议至少配到“本组织”，否则基本查不出数据。
5.3 报表数据源SQL中的组织字段
这部分属于进阶经验。自由报表的数据源如果是自定义SQL，建议在SQL里显式加上组织过滤条件。比如：
select c.pk_org, c.orgname, sum(c.tax_money) as total_money from so_sale c where c.pk_org = #{pk_org} group by c.pk_org, c.orgname加了这个条件后，报表查询前系统会把当前操作员的组织权限注入到#{pk_org}中。这样即使数据权限漏配了，也不会把整个表的全量数据暴露出去。反过来讲，如果SQL里没有组织条件，NC的权限框架就会被迫在内存里做过滤，数据量大时容易查不动，甚至超时。
5.4 报表查询按钮的“参数绑定”
还有一种坑，出现在报表模板设计阶段。自由报表的查询控件需要绑定数据集参数，如果参数绑定写死（比如把组织参数绑定到某个固定值），无论用户怎么切换组织，系统都只会用那个固定值去过滤数据。
这种问题表现是：用户A查询正常，用户B查询正常，但用户A切换到B的组织就会报错或数据为空。查一下模板的查询参数设置，看看组织参数是不是绑定成了固定值或全局变量，最好是绑定为系统的当前组织变量。
5.5 配置完成的“三重确认”
配置结束后，不要急着收工，请务必做三重确认：
- 角色功能权限里勾选了报表节点；
- 数据权限规则里组织范围覆盖了目标业务组织；
- 用户重新登录后，用真实业务账号跑一遍完整查询流程。
这三个条件缺一不可。我见过太多项目，前两个都配好了，结果用户还是报错，最后发现是没重新登录，旧会话一直带着旧权限。这种低级的失误，在项目上线阶段尤其容易出现。
5.6 日志定位法：从后端日志里找线索
如果上面的步骤都做了还是查不出问题，那就得看后端日志了。NC的服务端日志通常记录在中间件目录下的logs文件夹里，搜“query”或“permission”相关关键字，能看到权限拦截的具体异常堆栈。
举个例子：有一次用户报“没有组织权限”，我们在日志里看到一个PermissionDeniedException，异常信息里带了组织编码。顺藤摸瓜，发现用户确实没有被授予那个组织的访问权限，和数据权限配置对比后发现是职责冲突了——用户挂了两个角色，一个角色有权限，一个角色没有，NC在判定时取了交集。
这个案例的关键就是：权限配置有时不是“有”和“没有”的二元问题，而是多个角色之间存在冲突。
6. 常见问题排查思路与实用技巧
这一节整理几条实战中反复用到的排查思路和小技巧，算是我这几年跟NC自由报表“纠缠”下来的一点压箱底心得。
6.1 问题排查思路总结
遇到“查询数据出错，用户没有组织权限”，我的排查顺序固定如下：
- 用管理员账号复现，判断是配置问题还是报表本身问题；
- 查功能权限分配，确认报表已分配给用户或角色；
- 查数据权限规则，确认组织范围覆盖业务组织；
- 查用户所属组织和默认组织，确认登录上下文正确；
- 查缓存会话，重新登录或清理系统缓存；
- 查NC日志，确认异常堆栈并定位具体拦截点。
这套流程每次都能快速收敛问题范围，比东一榔头西一棒子高效得多。
6.2 实用技巧：写报表SQL时，留好“后门”
这条属于个人习惯，分享给大家参考。我在写自由报表数据源SQL时，习惯加一个“是否过滤权限”的开关参数。比如：
select * from ( select ... from ... ) t where ( #{is_control} = 'N' or t.pk_org in (select pk_org from ...) )这样在排查权限问题时，可以先临时把is_control设为N，确认数据本身没毛病，再切回Y排查权限问题。实际用在大型报表调试时，这个开关能省掉一半的排查时间。
6.3 实用技巧：批量分配报表权限的小工具
如果项目里报表数量多、用户角色复杂，逐张分配权限太累了。NC里有资源权限的“批量分配”功能，可以对角色一次勾选多张报表。另外有些客户会用系统的“REST接口”去批量绑定权限，这需要二次开发，但上线时省力很多。
我建议在项目初始化阶段，就把所有自由报表整理成清单，按模块分组，明确每个模块的授权角色，然后批量分配。不要等上线后一张张补，那种做法又慢又容易漏。
6.4 心得：权限问题往往不是“配置”问题，是“设计”问题
最后分享一个我踩过多次坑之后的体会。
很多团队把权限问题当成运维问题，谁报错就去给谁加权限，加一次好一次，过两天又换个人报。这种“头疼医头”的方式，短期能交差，长期是给项目埋雷。更深层的做法，是梳理清楚业务组织和角色的映射关系，把“谁能在哪个组织下看哪些报表”一次性定清楚，形成权限矩阵文档。
权限矩阵建议至少包含三列：组织层级、角色、报表清单。比如某集团客户，我帮他们整理了一张权限矩阵，集团财务部“财务分析岗”对应全集团所有财务报表，“应收会计岗”只对应本公司应收类报表。按这张表配置完，后续再也没有接到过“没有组织权限”的电话。
NC这套系统的逻辑，说复杂也复杂，说简单也简单——把组织和数据的关系对齐，权限自然就通了。报表报错只是表象，真正的功夫在权限模型的梳理上。
7. 两种边界情况：真没权限和伪权限问题
排查过程中，还要区分两类情况。不然容易陷入一个死循环：调了权限还是不好使，不好使就再调，反复横跳。
7.1 真·没有权限
这属于权限体系本身就拦截得对。比如用户A只负责北京公司的应收业务，他查上海公司的报表，系统当然会拦。这不是Bug，是权限控制的正确行为。这种场景下，你要做的不是绕过权限，而是明确业务上用户A是否真的需要看跨组织数据。如果确实需要，就增加相应组织的数据权限；如果不需要，保持现状即可。
7.2 伪·权限报错
有些情况看似是权限问题，实际上是“查询数据出错”和“用户没有组织权限”两段文案连在一起造成的误解。报表模板里有字段级权限控制、公式错误、数据集SQL执行异常、甚至数据库连接超时，都可能抛出类似的组合提示。
判断到底是哪一类，最简单的方法是看日志。如果在日志里能看到明确的ORA-、SQLException或超时异常，那大概率不是权限问题，而是数据源或数据库层面的故障。不要因为报错文案里有“权限”两个字，就一直在权限配置里打转。
提示：把报错当成线索，不要当成定论。多花五分钟看日志，比盲调权限省时间得多。
8. 实操总结与个人体会
写到这里，把方法、场景和踩坑经验都过了一遍。如果让我用一句话总结：NC自由报表的“没有组织权限”，十有八九是功能分配或数据权限没有配置对齐，少数情况是缓存和会话导致的旧权限残留，真正需要动SQL的反而很少。
我在实际项目中摸索出来的体会是：跟NC这种老牌ERP打交道，一定要有耐心，更要讲究方法。权限体系虽然看着繁琐，但它的设计目标是明确的——数据不出组织边界。理解了这一点，你就不会抱怨它“矫情”，反而会顺着它的脉络找到问题所在。
也因为这个原因，我后来在给客户做NC自由报表时，从来不先写SQL，而是先把权限矩阵和报表授权清单梳理出来，再动手设计报表。前期多花两小时，后期能省下好几天的返工时间。
最后再分享一个小技巧：如果你改了权限之后，用户那边还是持续报错，先别急着清理服务器缓存，先让用户完全关闭浏览器，重新打开再登录一次。别问我怎么知道的——有一次我把服务器缓存放了个遍，最后发现是用户浏览器标签页的旧页面一直没刷新。
