|
马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。
您需要 登录 才可以下载或查看,没有账号?注册账号
×
这个坛子真是高手如云啊,雕虫小技实在不敢献丑,不过看到还是有很多想学和初学用友软件的朋友,还是抱着
抛砖引玉的态度总结一下今天自己解决一个客户问题的过程。希望对大家都帮助。
问题描述:
应收明细账查询条件选择客户A,日期区间为3-3,查询后出现一条记录,日期为6月34日,收付两栏都有
金额。
问题分析:
这类的报表都是用报表控件开发的,系统在tempdb库生成一个名为AP。。。。的临时表,然后报表控件把这个
临时表的数据读出,然后在前端进行小记和分组汇总等运算,最后展示出来。
理解这一层了以后,就可以对问题的根源进行分析。
首先打开这个报表,这时报表展现出来,错误的数据也包含在其中。
然后进入企业管理器,在tempdb库中找到那个临时表,检查数据有没有问题。并没有发现iMonth字段为6iDay
字段为34的记录,那证明原始数据的生成时没有问题的,问题出在报表生成的过程中。我又看了一下报表展示的两栏
金额,发现这两个数据分别属于两条记录。并且这两条记录的月份都为3,日期分别为11和23。日月分别正好等于6-34
熟悉SQL语法的朋友自然就联想到了,是GROUP BY的后缀出了问题,日、月字段的分组汇总方式也不对,不应该是sum。
现在是select sum(iMonth),sum(iDay),sum(AA)... from tempAp88888 ....group by AA...
导致当其他分组条件相同时,对iMonth,iDay进行了求和,那么只要不对他们求和就可以了。但是从sql语法可以知
道,不包含在聚合函数中的列是要放在group by之后的。报表分组运算是否把某列放到GroupBy后取决于报表格式设
置中的“分组”选项。
基于以上理论基础,开始解决问题。
解决方案:
进入报表的格式设置,第一眼就发现iMonth和iDay的备注都是Sum,显然不是我想要的,删掉备注的值。
然后发现“分组”项都是不能分组,那意味着列不会被放到Group By之后,改成“分组”。
关闭模块,重新查询,正确的结果已经出现。但是美中不足是在选择查询条件的时候月和日的分组汇总状
态是可选的,也就是说客户可能会自己改成不分组,遇到矫情的客户还不好解释,那就比较郁闷了。
哈哈,这么解决。进入格式设置,设置iMonth和iDay的备注为GroupHold,顾名思义,就是分组状态锁
定了。客户想改也改不了,再问就告诉他,用友公司就是这么规定的,这个必选。就OK了。
U6的自定义报表是个非常灵活的工具,大家要是有兴趣可以深入研究研究,一定会有意想不到的收获哦。 |
评分
-
查看全部评分
|