随着科技的进步，用户越来越关注数据。关注数据的时效性，数据的准确性等。如果发现数据被修改，在数据量大的情况下，哪条数据被修改，查询起来相当麻烦。本篇文章小亿就为你支一招，数据留痕，数据改变，即刻知晓。

数据留痕简介

什么是数据留痕?数据留痕指程序自动记录数据多次修改上报的历史变化情况，供填报人员及数据管理员随时查看和统计。

1功能特色

【详细的留痕记录】除了能查看数据修改前后的值和用户外，还能查看修改时间、IP等信息。

【丰富的查询入口】可以按照任务、报表、表元来查看数据留痕记录。

【全局的统计分析】通过图、表展现历史数据的直观分析，从粗粒度到细粒度展现。

2应用场景

填报人员上报数据一段时间后，发现数据被修改过，可以通过该功能了解谁在什么时间改了数据；数据汇总人员再次汇总数据的时候发现数据前后不一致，可以通过该功能了解两次数据汇总的差异以及谁修改了明细数据；数据管理人员通过数据留痕统计，可以掌握哪些单位数据在多期没有变化，可能是质量不高的数据。

数据留痕实现

对数据留痕有了简单的认识后，那如何实现数据留痕呢？

1任务留痕设计

首先设计任务时，需要增加数据留痕代码组。

代码组设计完成后，在使用设计系统或插件设计任务时，选择“定义”下“自定义属性”菜单，

分别给表元，报表，任务增加一个自定义属性：sjlh；属性中文名为：数据留痕；对应代码组：数据留痕。

根据实际需要，分别给任务，报表，表元设置对应的属性值。

2属性设置

数据留痕需要监听器配置，在“报表平台属性”中添加服务器属性，增加上报数据时留痕明细的监听器配置。

根据实际需要，可配置全部任务默认留痕明细设置。在“报表平台属性”中增加对所有任务表元明细留痕的默认设置，该项为可选项。

配置项sjlh表示是否对所有任务默认进行表元明细留痕， 0表示默认为不允许留痕， >0 表示允许留痕， 如不配置则以当前任务设计的设置为准。

说明：

sjlh属性在服务器、任务扩展属性、报表扩展属性、表元扩展属性上都可以配置。

3启用数据留痕

在任务属性配置中， 需要勾选任务属性“允许数据留痕”选项。当勾选"允许数据留痕"时表示启用数据留痕功能。

4查看数据留痕

如果数据发生了修改，用户在报表界面右键“报表历史”， 可以查看数据修改的详细历史。

留痕开关优先策略

sjlh属性在服务器、任务扩展属性、报表扩展属性、表元扩展属性上都可以配置。这几者之间居有一定的优先级别。

表元扩展属性设置

系统字段不进行数据留痕，只有表元才进行数据留痕。

如果表元的扩展属性sjlh=1，该表元数据留痕。如果表元的扩展属性sjlh=0，该表元不进行数据留痕。如果表元的扩展属性未配置，遵循以下规则。

报表扩展属性设置（表元属性未配置时参考该规则）

报表扩展属性sjlh=1，数据留痕。报表扩展属性sjlh=0，不进行数据留痕。报表扩展属性sjlh未配置，遵循以下规则。

任务扩展属性设置（表元、报表属性都未配置时参考该规则）

任务扩展属性sjlh=1，数据留痕。任务扩展属性sjlh=0，不进行数据留痕。任务扩展属性sjlh未配置，遵循以下规则。

服务器属性设置（表元、报表、任务属性都未配置时参考该规则）

server.property中寻找sjlh的值。0表示不进行数据留痕，其他值表示进行数据留痕，未配置不进行数据留痕。

留痕明细必要条件

除属性设置外，报表要将修改变更情况记录到痕迹明细表还需满足以下规则：

第一次上报数据时，不作留痕明细处理。留痕明细处理在报表户数据第二次上报时候触发，保存数据不作留痕处理；汇总户不需要数据留痕，只有基层户的上报操作才进行数据留痕；只有主数据集进行数据留痕，其他数据集的上报数据操作暂不考虑留痕处理；任务属性必须勾选数据留痕选项。如果该选项中途被去掉，不管用户上报多少次都不进行数据留痕。在该选项被再次勾选后，用户上报后获取的修改前值是该选项被去掉之前的最后一次修改值。变长表必须设置关键字，且关键字不允许重复。如果某变长表没有关键字或者有关键字但允许重复，该变长表的所有表元都不进行数据留痕。如果变长表关键字被修改，表示该数据行删除后新增，此时记录删除操作，并同时记录新增操作。

曾经以为开源报表是免费的，这个“曾经”指的是2008年之前，那个时期人工成本很低，很多软件公司用几个工程师，拿开源的报表改一改、写点代码，虽然样式难看，不太复合客户的要求，也就只能凑合了。一些网上论坛甚至为此开专版讨论 JAVA 报表，里面都是热火朝天，发问者甚众，一时间好不热闹。

2008年之后，一方面，随着皕杰报表、帆软等国产中式报表工具快速崛起，这些国产报表在解决中国报表需求复杂性和多样化方面有着明显的优势，开创类Excel报表设计新模式、多源数据的卓越处理功能等，极大的提升了报表的开发效率；国内厂商提供本地化的贴心的技术服务，而开源报表压根不存在严格意义上的技术支持。

另一方面，随着人工成本的上升、报表日益复杂的要求，在论坛里，象“请教高手 ireport 某某问题如何解决？”之类的帖子，发问者往往也是在线苦苦等候答复。运气好的在线能等到，运气不好的那就等着吧。如果碰到的正好是个没解的问题呢？或许会有热心观众参与讨论，解决办法还得自己想。掰着指头算算，花在这问题上的时间、人工成本日益增加；仅仅Java工程师一个月的成本就超出了商业报表工具的购买费用，这还不包括导致的项目时间拖期、人工效率的损失等各种隐形的成本。

由此可见，用开源的报表是最昂贵的，随着皕杰报表等国产中式报表工具成为国内Java报表的中流砥柱，开源报表的没落也是必然的！

亿信华辰报表软件i@Report支持各种类型的报表，如基本表、变长表、中国式复杂报表、套打、问卷调查等。可灵活地设置各单元格风格，包括：文本、数字、图片、日历、附件、下拉框、下拉复选框、输入复选框、单选按钮等

1、制作基本表

基本表拥有固定的行与列，假设制作一张六行三列的基本表，下面以该表为例，介绍如何制作基本表。

首先新建一张6×3的基本表，

选中A1表元，输入"证件类型"，以此类推，在B1、C1表元中分别输入"证件代码"、"股东名称"，输入完毕，A1、B1、C1均自动变为固定表元。

选中A2~A6表元，右键点击选中区域，打开表元属性对话框，将数据类型修改为"字符串"，并使用代码组"股东证件类型"，修改完毕，A2~A6表元自动变为代码组表元。

选中B2~B6表元，右键点击选中区域，打开表元属性对话框，将数据类型修改为"字符串"，数据长度修改为"18"，设置完毕，B2~B6表元均变为18位的字符串型变量表元。

选中C2表元，点击

，在弹出的公式定义向导对话框内输入公式if(B2=null,"",self())，表示若B2表元为空，C2表元值为空，否则返回C2表元自身的值，同样为C3~C6表元定义公式，定义完毕。

点击

，在表体上方拖动鼠标，在拖动区域内输入表头"股东信息表"，

编辑报表文字的字体、颜色、居中等。点击

，在弹出的审核公式对话框内为当前报表添加审核公式。

右键点击报表的空白区域，打开报表属性对话框，为报表设置报表代号、报表简称、报表详细名称等信息。

2、制作审核情况说明表

用户进行数据填报时，某些未通过审核的数据填写审核说明后，系统将该审核信息记入审核情况说明表，记入审核情况说明表的数据即使未通过审核也能上报。

首先新建一张8×3的变长表，

第一行表元内输入相应的文字，

将表元视图切换为字段名，第二行表元内分别输入字段名RPNAME、PLANARKEY、AUDITTAG、AUDITEXP、AUDITNOTE、AUDITINFO、AUDITOK与AUIDTTIME，各表元的数据类型和字段长度要求参考下表 ，

其中，字段AUDITOK表示不删除审核说明记录，该字段为"0"时，表示审核未通过；该字段为"1"时，表示审核通过。

将表元视图切换为正常，为第二行表元均定义公式：self( )。

添加表头，并隐藏第三行，即合计行。

右键点击报表空白区域，打开报表属性对话框，切换至变长表选项卡，点击自定义关键字处的

，将A2、B2、C2表元设置为关键字表元。

打开任务属性，切换至“审核设置”选项卡，选择审核明细表，定义审核标记前缀，勾选“需要填写审核说明”与“忽略已填写审核说明公式”。

编辑允许填写审核说明的审核公式，打开对应的审核公式定义对话框，勾选“允许填写审核说明”。当用户填报数据时，如果未通过审核，填写审核说明后对应未通过审核的数据将记入审核情况说明表。

3、制作视图表

视图表是一种分析表，是一种能将某一报表户的分散在多张报表中的数据集中在一张报表中的分析表，方便打印输出。

与其他分析表不同，视图表只从单个报表户取数。一个视图表可以从多个基本表中取数，也可以包含多个变长表。由于是一个分析表，所以视图表的行列数可以很多。视图表的数据会随着当前报表户的变化而不同，因为它总是实时地从当前用户的一套报表中取值分析的；而其他类别的分析表都是对下级单位数据的统计分析，不管当前报表户是哪一户，分析数据总是根据分析表中设定的条件统计产生。

以一张4×7的视图表为例，介绍如何制作视图表。

新建一张4×7的基本表，选定全表表元，点击

将所有表元设置为固定表元，合并A1~G1表元、A3~B3表元、A4~G4表元。

右键点击A1表元，选择属性，打开表元属性对话框，在链接报表处选择需要链接的报表B0，同理，为A4表元设置链接报表B1。

为视图表添加按钮表元，通过点击按钮表元，可以控制其他链接报表表元的新增记录、保存记录、删除记录等操作。以A2表元为例，该表元处需要定义一个"新增记录"按钮，打开表元属性，在"url链接"处输入脚本，输入完毕保存表元属性。

分别为功能按钮表元定义"url链接"，相关按钮的脚本的设置可参考下表。

所有的功能按钮表元链接定义完成后，一张视图表制作完成。

     之前的文章已经大致给大家介绍过大数据计算引擎-润乾集算器了。想必很多人还是心存疑惑，集算器作为大数据分析系统，到底它能做些什么呢？这篇文章，就为大家详细介绍。

降低报表开发难度

降低开发难度从而提高开发效率是集算器的设计初衷，是最容易理解的作用，前面已有粗略介绍。

这方面的细节内容太多，我们会再做一个专门话题详细讲述集算器如何解决报表开发中的各种具体难题以及与常规手段的对比。在这里只做总结性地阐述。

比Java和SQL更易写

如前所述，集算器的设计目标是为了解决报表的数据准备，而目前这个工作一般采用Java或复杂SQL完成，存储过程及中间表也可以算作是SQL。

与Java这类没有提供直接结构化计算的语言相比，采用集合化语法的集算器代码会更为短小，这很容易理解，毕竟集算器基于Java提供了更高层的类库和方法。

短小不仅仅是写得快，而且还能容易理解和排错。一个页面内能看到更多的代码，从而能更完整地理解代码的含义。使用集算器编码时，伪实代码的比例大约是只有1.5:1，绝大多数报表的数据准备算法可以在一个屏幕内显示出来。

而使用Java就很难这样，几十行代码下来仅仅能做个简单的汇总，一个完整的业务逻辑动辄需要几百行代码，翻看到后面时已经忘了前面是怎么做的了。

除了代码本身简短的外，集算器特有的网格式编码和调试方式还能进一步强化这个特色。程序员可以在一行写多句相关的代码，某句长代码不必完全显示出来从而不影响查看算法整体结构，循环可以用更直观的方式呈现，单步执行和单元格变量可以随时查看每一步的结果而提高调试效率。

这些，都可以让程序员专注于数据计算中的业务逻辑而非技术细节。

与SQL这类本身就支持结构化计算的语言相比，集算器完善了对分步计算、集合化、有序计算和对象引用等几方面的支持。对于日期和字串等运算，集算器也比大部分SQL提供了更丰富的方法。

许多情况用SQL也不是写不出来，但不能直接按自然思维实现，很费脑筋，这种代码放时间长了程序员自己都会忘了是怎么写出来的，给将来的维护也造成麻烦。

集算器代码则没有这些问题，符合自然思维习惯，即使是与SQL相同的思路也能更清晰地表达，很容易理解和维护。

比报表中计算更广泛

报表工具一般都可以完成计算列、分组排序等运算。基于非线性报表模型的工具还提供了跨行组和相对格与格集引用方案，可以完成相当复杂的运算。

报表呈现环节的计算是一种状态式的计算。所谓状态式计算，就是把所有计算表达式一次性都写出来，由报表工具根据依赖关系决定计算次序。这种直接把运算写到布局中的好处是很直观，在依赖关系不太复杂时能一目了然地了解各单元格的运算目标。

但是，在依赖关系较为复杂，计算需要分成多步时，这种状态式计算就显得困难了。还有的时候，计算的中间结果并不要呈现，这样就会出现隐藏格。隐藏格不仅将很大程度地破坏状态性运算的直观性，而且还会导致运算效率低下，占用更多内存。

比如要列出销售额占前一半的大客户，这时就有典型的过程性计算，在报表中要使用隐藏行列手段将不该列出来的条目隐藏，而不能直接过滤掉。再比如带明细的分组报表要按汇总值排序，这需要先分组再排序，而采用状态式计算的报表工具无法控制这个次序，这个报表也就无法完成了。

对于这类过程性计算或需要隐藏格的复杂报表，采用集算器在数据准备阶段完成计算，报表只负责呈现及少量的直观计算，可以有效地保留状态式计算的优势。把复杂运算到集算器完成，过程虽然多了一步，但结构更为清晰。

数据准备还能解决动态数据源和数据集的问题。报表使用的数据源一般是在报表工具中配置的，不能根据参数动态选择，而使用集算器数据源时就可以用脚本控制连接不同的数据源。通用查询报表要求数据集取数SQL不能简单地用参数控制，而要整体替换，支持宏的报表工具能够一定程度地解决这个问题，但面对要将宏计算后才能拼进SQL的复杂场景也会感觉困难，而采用集算器数据集则无论是否支持宏、需要多复杂的宏计算都可轻松应对。

数据准备不仅能解决报表中的计算，还能协助处理格式。比如许多报表工具都支持纵向分栏，但很少有报表工具支持横向分栏。对这种需求无法处理，而采用集算器可以方便地将原数据集变换成横向拼接过的数据集。报表工具只要用普遍的模板呈现一个列数更多的数据集即可。再比如许多报表工具不支持末页补足空行，也可以用集算器在返回数据集时补。 

一致的多样性数据源支持

报表的数据源并不只是关系数据库，还可能是TXT或json等文件，而文件没有计算能力，所以常常要有一个过程将这些数据导进数据库，增加开发工作量。

如果采用集算器准备数据，则可以直接用这些文件作为数据源去生成报表，不需要导入数据库的过程。

数据库包括NoSQL数据库、文件包括HDFS文件，对于集算器来讲都是数据源。集算器自有的计算能力可以使这些计算能力不一的多样性数据获得通用一致的计算能力。比如文件几乎没有计算能力，MongoDB对JOIN和GROUP运算支持不足，各家SQL对窗口函数的支持程度不同、日期与字串处理能力也普遍不足且风格迥异。这些数据源都能基于集算器采用一致通用的方案来计算，而这将意味着更低的移植成本以及学习难度。

 接下来的文章，还将继续为大家介绍大数据计算引擎-润乾集算器。

前文大致已经给大家介绍过集算器和集算器的作用了。可能还会有许多人心存疑惑，这标题不是报表工具的二次革命吗？集算器能为报表工具做些什么？又是怎么能够提升报表计算能力的？又能否提高结构化计算能力？这篇文章会解开大家的疑惑。

优化报表应用结构

虽然提高开发效率是集算器的初衷，但优化报表业务的应用结构才是集算器更重要的作用。可以说，集算器的出现是报表工具的二次革命。

解释执行降低应用耦合度

Java是编译型语言，代码需要事先编译才能执行，虽然也有动态加载技术，但在难度和复杂度都要大许多，一般应用程序员不常使用。这种情况下，采用Java编写报表数据准备算法将导致报表部分与主应用程序的高耦合性，具体来讲有这么两方面：

1.Java程序要和主应用一起编译并一般放在一起部署，这样用报表工具在外部开发出的报表模板报表就需要和应用程序中数据准备算法配合才能工作，难以将本来相对独立的报表功能作为一个模块处理。

2.相对于主程序，报表的修改更为频繁，如果牵涉到数据源的变动，则必须要改写相应的Java程序，导致整个应用重新编译部署，很难做到热切换。

如果用集算器替换Java实现数据准备算法，则能有效地降低主应用程序与报表功能的耦合度：

1.集算器写出来的算法也是类似报表模板的外置文件，不需要和主应用程序一起编译打包，而可以和报表模板放在一起管理维护，从而使报表功能模块化。

2.集算器是解释型执行的语言，在修改时不需要涉及主应用程序，只要把集算器脚本替换就可以，很容易做到热切换。

另外，Java编写的算法一旦加载执行就会占据内存不再释放，即使相应的报表不再被访问。而使用集算器就不会有这个问题，算法执行完比后会立即释放，不再占用内存。

算法外置减少存储过程

采用存储过程实现数据准备算法和用Java类似，依然会造成耦合度的问题，只不过不是报表与主应用程序之间的耦合，而是报表与数据库之间的耦合：

1.存储过程存放在数据库中管理，报表模板在外部文件系统中管理，两者要对应起来麻烦度很大

2.存储过程修改时需要申请一定的管理员权限做重编译，虽然不象Java那样难以做到热切换，但数据库高权限的频繁使用会带来安全隐患。

3.比Java更糟糕的是，数据库及其中的存储过程可以被多个应用程序共享，如果管理不善，很容易造成多个应用之间的高耦合，时间长了会搞不清楚某个存储过程在被哪些应用调用，越来越混乱。

存储过程本身编写难度并不小，且强计算型代码的性能也不佳，原则上在报表业务中应当尽量少用存储过程，除非个别涉及数据量巨大难以移出库外计算的情况。

频繁使用存储过程要求高超的管理能力和巨大的管理成本，但这是大多数应用开发团队不具备的能力或不能承担的成本。

同样地，采用集算器也可以极大程度地减少数据库中的存储过程，算法外置后与报表模板一起存放管理，完全归属于应用本身，不仅降低与应用其它部分的耦合，更不会造成与其它应用的耦合。

数据外置减少中间表

所谓中间表，是指因为数据量或计算复杂等原因，直接基于源数据生成报表在性能和复杂度方面不可容忍，事先将数据整理汇总成的某个中间结果。报表的开发基于这些中间表进行，可以降低难度和提高性有

因为不可能为每个报表的每种参数状态计算中间结果，在生成报表时还需要进行一些即使较为简单的计算，也就是要求这些中间结果仍有计算能力。最容易获得的计算能力来自数据库，因此这些中间数据经常会被存储到数据库中。

与存储过程类似，使用中间表也会造成数据库管理的混乱。

关系数据库中的表是以线状方式存储的，相当于没有分类，各个应用用到的中间表混到一起，很难搞清楚。想管理好就需要强有力的控制能力，比如规定中间表的命名规则并保证得到执行，但强化管理常常是以牺牲开发效率为代价的。

如果管理不善，就会导致中间表越来越多，这其实是现实应用建设中经常看到的结果。有些数据库中会积累出上万个表，绝大多数都是为报表服务的，其中有相当多部分已经没有意义了，但因为不清楚有哪些应用还在使用这些表而只能保留，相应的ETL过程也仍然在毫无意义地浪费计算资源向其更新数据。

数据外置可以有效地减少中间表。

中间数据一般都是由不再改变的历史数据计算出来的，完全不需要数据库的事务一致性能力，因为是导出的冗余数据，也不需要很高级的安全稳定要求，存在数据库中仅仅为了获得计算能力。如果我们有办法让中间数据存放在文件系统中且拥有计算能力，那就没必要让这些数据占据昂贵的数据库空间了。

集算器能够实现这一目标。

外置的中间数据可以使用文件系统的树形结构管理，与报表模板及数据准备算法统一存储，而集算器可以使这些数据继续拥有强大的计算能力为报表服务。这样，不仅管理简单方便，而且可以少占用数据库空间而成本更低，再者，文件系统还有比数据库更高效的IO性能，更适应于报表业务。

混合运算实现T+0报表

关系数据库强大的事务一致性能力目前在业界尚无有效的替代者，为保证交易的完整性，当期还在变动的数据仍然有必要存放到关系数据库中。

然而，为了实现T+0报表，我们还需要把历史数据继续存放在当期数据库中一起计算，而历史数据常常要庞大得多，这会要求我们建设更大容量的数据库，显然会导致更高昂的成本。而且这个量并不可能一直增长上去，太大了会直接影响当期交易业务的性能。

为了解决这一矛盾，通常的办法是只保留部分历史数据在当期库中，把远期的历史数据被移出独立成库，这样的结果是只能查看近期的报表或远期的报表，但不能查看混合的报表，不能做到真正的T+0报表。

当然，还可以把当期交易库和远期历史库混合运算生成T+0报表，这就需要跨数据库的混合计算能力。

理论上许多数据库都支持这种跨库运算，一般是将外库数据映射进本库，实际运算时要取数据到本库执行，这样在应用中的性能和稳定性都较差，实施成本不低。而且历史库的容量较大但不需要事务一致性的功能，很可能被建设成与当期库类型不同的数据库，这样数据库厂商本身提供的跨库运算机制就更难实施。

集算器可以完成这个混合计算任务。

集算器自有的计算引擎不依赖于某个数据库，各库内的数据计算仍由各库进行，将各自的运算结果取到由集算器汇总处理，再将结果传给报表工具去呈现，从而即可实现全面的T+0报表。显然，这种机制还方便横向扩展，历史库可以有多个不同类型的数据库。

而且，在集算器的支持下，历史数据还不必一定要以数据库的形式存放，可以存储在IO性能更好的文件系统中，配合集算器的集群服务，可以在更低廉的成本下获得更好的性能。

直接使用多样性数据源

集算器支持多样性数据源。比如NoSQL数据源，文件数据等，都可以被集算器直接计算而不必导入关系数据库，这样可以不再建设多余的数据库，成本更低而且降低数据不一致的风险。

这些非关系数据库在某些方面比关系数据库更强，只是计算能力不足或不同，如果用集算器辅助，则可以保留其原有的优势。比如MongoDB的对追加型日志数据的吞吐能力就远远超过普通关系数据库，但结构化计算能力较弱，用集算器来弥补则可以数据继续保留在MongoDB中获得其高吞吐性能。

想了解更多集算器的文章，请继续关注我们。

随着信息技术的飞速发展，ERP系统逐渐被广泛应用于生产制造企业中，利用数字化制造流程，推动收入增长，节约更多成本，创造更高利润。本文，怡海软件将撇开ERP软件产品本身，来简要描述一下生产制造ERP系统的主要功能模块，即它为生产制造企业做什么。

财务管理

企业中，清晰分明的财务管理是极其重要的。所以，在ERP整个方案中它是不可或缺的一部分。ERP软件中的财务模块与一般的财务软件不同，作为ERP系统中的一部分，它和系统的其它模块有相应的接口，能够相互集成，比如：它可将由生产活动、采购活动输人的信息自动计人财务模块生成总账；会计报表：取消了输人凭证繁琐的过程，几乎完全替代以往传统的手工操作。

企业可通过采用一整套旨在简化财务运营的工具，提高利润，减少错误，并制定能带来更多盈利的决策。

1、会计

会计核算主要是记录、核算、反映和分析资金在企业经济活动中的变动过程及其结果。

▲利用ERP能自动处理所有重要的会计流程，比如日记账分录、应收账款和应付账款；

▲实时执行结算任务和跨期流程，加快结算速度，提高合规性和控制力，并减少结算工作量和成本。

2、成本控制

主要是基于会计核算的数据，再加以分析，从而进行相应的预测、管理和控制活动。

▲更高效、更准确地管理现金流，跟踪固定资产，控制预算以及监控项目成本；

▲你可以准确预测现金流，管理资金流动性并降低风险，提高现金余额、现金需求和流动性战略的一致性。

3、固定资产管理

▲基础数据管理齐全，如资产名称、资产数量、资产原值、资产地点、取得日期、资产类别、资产处理方式、资产状态、资产用途、资产转移记录、使用年限等；

▲利用虚拟功能，简化固定资产的管理，消除重复的手动数据输入工作；

▲提供多角度的报表查询与分析功能，包括固定资产明细表、固定资产金额变动明细表、固定资产折旧汇总表、固定资产年度折旧明细表、固定资产分类总账、固定资产来源分析表等。

4、银行业务和对账

▲通过支票、现金和银行转账等各种方法，更快速地处理对账、银行对账单及付款。

5、财务报告和分析

▲利用实时数据创建标准或定制的财务报表，完善业务计划和审计复核流程；

▲借助其财务规划和分析流程功能，你可以缩短规划周期，提高盈利能力，并提升财务部门的工作效率。

（PS：有关ERP系统财务管理模块的更多详情介绍，大家可查阅怡海软件之前发布的文章，ERP系统在企业财务管理中的应用）

采购和物流管理

管理订单到支付的整个周期，包括收据、发票、纳税申报表和付款等，帮助企业优化采购实践，并控制成本。

1、生产控制

生产控制管理是一个以计划为导向的先进的生产、管理方法。企业首先确定一个总生产计划，再经过系统层层细分后，下达到各部门去执行。即生产部门以此生产，采购部门按此采购等等。

▲将企业的整个生产过程有机的结合在一起，使企业能够有效的降低库存，提高效率；

▲使各个原本分散的生产流程的自动链接，也使生产流程能够前后连贯的进行，而不会出现生产脱节，耽误生产交货时间。

2、采购管理

▲确定合理的订货量、优秀的供应商和保持最佳的安全储备，能够随时提供定购、验收的信息，跟踪和催促对外购或委外加工的物料，保证货物及时到达；

▲建立供应商的档案，用最新的成本信息来调整库存的成本；

▲通过在简单易用的界面中管理详细数据，集中处理采购流程；

▲查看账户余额和采购分析结果，同时维护包含价格表和税费信息在内的详细物品采购信息；

▲简化采购流程，比如采购申请、采购订单、收货创建和退货管理；

▲通过匹配凭证，查看信息线索和处理多种货币，完善审计流程。

3、仓库管理

它是一种相关的、动态的、真实地库存控制系统。

▲通过库存管理来控制存储物料的数量，以保证稳定的物流支持正常的生产，但又最小限度的占用资本；

▲结合、满足相关部门的需求，随时间变化动态地调整库存，精确的反映库存现状；

▲实时同步收货单和仓库库存水平，从而轻松执行采购计划。

4、应付账款

▲降低成本，优化供应链关系；

▲自动根据采购订单或收货单创建应付账款发票；

▲参考采购订单处理应付账款发票、注销和贷项凭证；

▲制定物料需求计划；

▲安排相应的采购活动。

5、报告

▲利用实时数据生成综合报表，并以各种形式或在仪表盘中显示报表，从而帮助你通过电脑或移动设备，全面了解对企业最重要的事务；

▲借助分析和报告工具，你能够基于企业数据，及时准确地创建报表；

▲捕获所有关键信息并支持整个企业即时获取这些信息，使员工能更快地作出有把握的明智决策。

销售与客户管理

销售管理是从产品的销售计划开始，对其销售产品、销售地区、销售客户各种信息的管理和统计，并可对销售数量、金额、利润、绩效、客户服务做出全面的分析。从初步接触客户到最终销售、售后服务和支持，更高效地监督整个销售流程和客户生命周期。

比如怡海软件提供的SAP Business One（面向小型企业的 ERP系统）工具，具备大量生产制造行业特定功能、最佳实践和流程，其销售与客户管理具备以下功能：

1、销售与机会管理

▲从首次接触到达成交易，全程追踪销售周期内的销售机会和销售线索活动。

2、营销活动管理

▲创建、管理和分析营销活动，将潜在客户转化为实际客户，提高销量和盈利能力。

3、客户管理

▲通过同步和管理 Microsoft Outlook 中存储的客户联系信息，集中存储所有重要的客户数据。

4、服务管理

▲高效起草和管理保修合同和服务协议，快速接收和响应服务请求。

5、报告和分析

▲利用模板，设计涵盖销售流程各个方面的详细报表，包括销售预测和管道跟踪等等。

6、移动销售

▲支持整个销售部门随时随地通过任何移动设备管理信息。

人力资源管理

ERP软件的核心人力资源功能，能帮助企业更有效地管理人力资源流程和事务、自助服务、工时和考勤，以及员工薪资及福利。

1、员工管理

▲针对员工数据和流程，提供单一真实信息源，高效管理所有员工；

▲制定职务模型，包括职位要求、升迁路径和培训计划；

▲一站式满足员工的所有 HR 需求；

▲根据员工的资格和条件，系统能提出针对其一系列的的培训建议。

2、组织管理

▲优化组织架构,利用覆盖所有职能部门的智能自动化功能，管理端到端的人力资源流程。

▲控制并调整人力资源流程，追踪员工数据，并执行与岗位有关的事件；

▲确定招聘需求，并批准招聘请求。进行招聘过程的管理，优化招聘过程，减少业务工作量。

3、工时和考勤管理

▲根据本国或当地的日历,安排企业的运作时间以及劳动力的作息时间表；

▲准确管理所有员工的缺勤记录，通过实时分析应计工时，自动化并加速执行缺勤管理；

▲管理员工的工时和考勤，更准确地规划、记录和评估考勤流程。借助简单、智能的解决方案，获取全面的洞察，有效管理员工。

▲通过考勤系统，可以将员工的实际出勤状况记录到主系统中,并把与员工薪资、奖金有关的时间数据导人薪资系统和成本核算中。

4、员工薪资及福利管理

▲根据公司跨地区、跨部门、跨工种的不同薪资结构及处理流程制定与之相适应的薪资核算方法；

▲灵活管理薪资结构和级差，高效管理大量变更；

▲与时间管理直接集成，能够及时更新，对员工的薪资核算动态化；

▲回算功能。通过和其它模块的集成，自动根据要求调整薪资结构及数据；

▲管理和交付员工福利，利用简化的员工福利系统，提高福利计划的执行效率，同时控制成本。

▲进行人员成本分析，可以对过去、现在、将来的人员成本作出分析及预测,并通过ERP集成环境,为企业成本分析提供依据。

ERP系统在生产制造业的应用，可削减供应链成本，提高盈利速度，缩短周期时间，以及最大限度地减少报废和返工，满足客户需求，并开辟新的收入流。

欢迎转载，转载请注明出处：怡海软件（http://frensworkz/）

产生背景

报表工具是润乾的主打产品，我们在这方面积累了丰富的经验，当然，也有教训。

现代的报表工具主要解决两个环节的问题：一方面是呈现，也就是把数据以表格或图形的方式展现出来；另一方面是数据计算，即计算出源数据中没有和不能直接呈现的数据，比如一些公式格、分组汇总排序等等。

这里说的报表，主要是指用户事先确定好格式和数据运算规则的报表，我们俗称为固定报表。自助报表，也就是业务用户可以自己简单拖拽可以完成的报表，不在此类。自助报表的话题我们会专门再讲。

十年前润乾首先提出了非线性报表模型，带来了报表工具的第一次革命。这个模型从根本上解决了报表（特别是中国式报表）的复杂格式以及表内的计算问题，以此模型的润乾报表也因此取得了一定的成功，现在这个模型已经成为报表工具的标准了。

但是，有了这样的报表工具，报表开发是否就很好做了？

“并不是！”

报表工具常常会宣称自己支持“零编码开发报表”，润乾报表当然也不例外地喊过这个口号，但要认真分析下来，这是一句空话。

为什么呢？我们发现，数据库中的原始数据有时并不能直接用作报表工具的数据源去呈现，而需要一系列运算转换过程，有的过程还非常复杂。

有报表开发经验程序员都知道，为报表编写复杂SQL是经常的事，存储过程以及事先准备的中间数据也是家常便饭，有时SQL和存储过程不好写的运算还需要采用自定义数据源即JAVA程序来处理。总之都需要大量的程序编码。

虽然大部分报表还是相对简单的，这类复杂报表总数上并不算多，但其占用的开发工作量却会占绝对的大头，开发10个用报表工具能直接完成的简单报表所用的时间可能也做不了一个需要编码才能准备好数据的报表。

那么，提升报表工具的计算能力可否解决这个问题吗？

广义地说是可以的，这就是集算器的产生背景。

但是，由于数据量和数据转换具有分步性的特征，而报表工具在呈现环节的计算一般都是状态式和全内存方式，这样，无论在容量和复杂度方面都只能是很少部分地缓解这个问题而已，即使是润乾报表这样以计算能力为核心优势的报表工具也不行，数据源开发工作量依然很大，这也是我们这些年的经验。

提升报表工具的计算能力不能放在呈现环节，需要给报表应用结构中增加一个数据准备环节，这就是集算器的作用。

换句话说，当代的报表工具已经把呈现环节的格式及相关计算问题解决得很好，但在数据准备阶段仍然差得很远，需要有另外的计算手段来弥补，而集算器就是这个计算手段。

理解集算器

集算器是一种程序设计语言，它有自己的语法体系。和普通的程序设计语言一样，集算器也是由程序员编码代码后执行获得计算结果。与报表工具中的计算目标不同，集算器并不追求零编码，而是追求简单编码。

集算器不是面向对象的程序设计语言，没有复杂的类继承和重载概念，有BASIC这类初级程序设计水平的程序员都能很快掌握。集算器是解释执行的动态语言，可以在运行过程中拼出代码执行，这样可以获得更大的灵活性，进一步降低程序设计的复杂度。

与Java等高级语言相比，集算器中提供了大量与结构化计算相关的基础对象和方法，这类运算在数据分析及报表数据准备中非常常见，因而可以使得代码比Java要短得多。

大家都知道SQL用来实现很零碎的多步运算很不方便，特别是与次序相关的运算，程序员常常要把数据从数据库中取出来用Java等完成。而集算器则正好在这方面做了强化，相当于把SQL与Java的优势统一起来，让程序员可以既可享受到类似SQL的批量集合式计算、又能获得类似Java的灵活性。

集算器虽然在大多数情况下的语法要比SQL更简单易写，但并不能取代SQL。数据从数据库读出的IO成本相当高，有些涉及数据量太大的简单运算，数据读出的耗时远远超过运算本身，这种情况还是放在数据库中运算更合适。

集算器本身是用Java开发的，与Java有天然的兼容性，而且集算器的设计定位就是被集成，所以与Java的集成性非常好，特别地，对于Java报表工具，用集算器为之提供数据源非常方便。集算器提供标准的JDBC接口，报表工具可以象访问普通数据库一样访问集算器，集算器的jar包也可以和报表工具一起部署发布，完全无缝集成。

这一点与其它如perl,python,R等其它脚本语言不同，这些语言在某种程度上也方便用于实现许多结构化计算（细纠起来还是不如集算器专业），但很难被报表工具调用。

接下来的文章，我们会继续为大家讲解计算引擎-集算器。想要了解更多，请持续关注我们的百家号哦。

最近看了两篇有关报表工具和商业智能BI工具对比的文章，其中一篇文章说BI完全可以替代报表工具。感觉说的有点绝对。

报表工具和商业智能BI毕竟还是各有所长的，报表工具不仅能做展示和查询，还具备数据填报功能，也就是说可以把数据录入到数据库里去。这一类工具像Rag、Fine、皕杰报表都可以轻松实现。而BI工具则主要侧重于数据分析，可以进行钻取、联动、切片、旋转等多维的数据处理。这一类工具以国外的Tableau、Qlik等为主，国内的一些BI工具也有了比较多的应用。报表工具做多维、切片、旋转等分析不满足，BI工具做复杂的中国式报表也不能满足，且不具备数据录入功能。

因而我要说，报表工具和BI工具都很强大，关键看你的需求是什么。你要制作各类数据报表和图形报表，选择报表工具足够了；你要对数据进行分析和处理，将结果呈现给管理者，为管理者的决策过程提供支持，只能选BI类工具。除了功能上的差别，毕竟二者的价格还是有很大差距的，能用报表完成的工具就不用BI工具。

bi报表工具选型这个话题老生常谈了，今天又有新视角，希望对大家有帮助。bi报表系统只是一个软件，但是却涉及公司很多部门很多方面，绝不是大家想象的价格越贵就越好。今天这篇文章从十个新角度去分析bi报表工具该怎么选，加上之前分享过的很多选项技巧文章，相信这么多的干货分享可以帮助大家对bi报表系统选型的知识有了量变到质变的收获。

　　废话不多说，接下来我们就直接进入主题：bi报表工具选型，从这十个角度切入。

　　1.目标受众群体

　　这个bi报表工具是面向企业高层领导还是IT部门的技术人员？如果是高层领导，那么你的BI工具需求肯定是偏向决策性更多一点，如果是公司IT部门，那就是说企业高层不是经常需要用到，反而是IT人员需要，通过优化企业信息化管理，来促进业务的发展。

　　2.深入了解工具的特点

　　这个工具的特点在哪儿？有哪些侧重点和侧重点是什么？使用这个工具可以提高到少生产效率？另外需要结合您的产品路线图考虑，这个工具是否符合整个工作的战略愿景？是否包含一些必备的功能，如易于理解和支持的数据源、过滤器、数据可视化等？某些BI工具可能会因为某些特性而在众多产品中出类拔萃，比如Tableau精美的可视化效果；某些BI工具不同时期可能产品的功能特色还不太一样。比如奥威软件的Power-BI，侧重于各行业解决方案，而Speed-BI则是偏向于大数据云平台。所以在引入工具之前，了解下您和您的团队需要哪些功能。

　　3.技术

　　技术方面，您应该了解BI报表工具支持哪些数据库。可以连接到预置系统吗？用户要怎样进行交互，通过浏览器、桌面应用程序或是服务器软件，还是都支持？BI工具支持哪些操作系统呢？Windows、Mac或者Linux？有什么运行硬件要求？技术是否与您当前或未来的状态保持一致？

　　4.协作

　　团队如何共同创建和更新输出可视化、模型和计算？该BI工具是否有助于知识和资源共享？是否可以将代码片段、模板或报告打包在更广泛的团队中使用？

　　5.学习

　　该BI工具附带可用的培训和学习材料吗？一些商业智能和分析工具简单且易上手，有些则需要更深入的培训。

　　6.社区

　　该工具是否拥有强大的在线社区、论坛或发烧友博客。当您遇到障碍时，要确保您能从专家或别人那里得到解决方案。

　　7.客户

　　客户评论可以作为选择该工具的一个切入点。看看正在使用它的公司有哪些，这些公司的规模怎么样，适用于团队还是个人？他们是否会再次购买？如果您实在摇摆不定，与这些合作公司取得联系并亲自问问情况。

　　8.支持

　　提供该工具的厂商是否有良好的售后服务，是否了解该如何为不同的客户提供支持。

　　9.增值服务

　　该工具是否有提供顾问或者提供围绕产品的增值服务？如果该工具非常复杂，则可以考虑通过第三方支持来启动您的数据分析工作。

　　10.价格

　　该产品的定价如何？它是否符合您预算，您是否愿意在超出预算价格上接受该工具？

　　看完上面关于bi报表工具该怎么选的建议，是不是感觉又更清晰一点了呢？其实小奥感觉说是新视角，不如说是在选BI工具时要全面考虑的十个基础问题。毕竟，做好充分准备再去选型bi报表系统，才能选到更适合自身企业的工具嘛。

前言

近来报表软件、商业智能、OLAP、数据分析等概念非常火热，作为关键基础环节的报表软件在市场上也是层出不穷，让人眼花缭乱，国内外的加起来细数一下，大概有二三十种之多。这些产品看起来实现的功能都差不多，那么，应当怎样选一款满足自己需求的报表软件? 在选型过程中不被厂商的宣传和演示牵着鼻子走？

在多年的报表经营过程中，我们发现许多用户在选择报表软件时会有许多认知误区，本篇将主要针对这些问题提供一些意见和建议供参考。

一个最常见的误区就是报表中间件和报表平台分不清楚，在演示过程中被平台类产品丰富的功能吸引，但其实需求却是要在项目中嵌入使用的报表工具。这一方面可能为多余的功能买单，另一方面还会带来难以集成的问题，多余的功能也如鸡肋一般，很难发挥作用。

要想避免这个问题，首先应该弄清楚需求（敲黑板，需求，需求，需求要明确）。是用于在业务系统中做报表，还是要上跨业务系统的报表管理平台？这两种需求看起来都是要做报表，但其实差别却巨大。

需求为前者时，我们要选中间件型报表工具。报表中间件的特点是报表和中间件，除了要有足够强大的功能将数据以报表和统计图的方式呈现外，还有个很重要的使命是 - 被 ~ 集 ~ 成 ~，快速被集成，为我们完善业务系统的报表模块提供便利。而当需求为后者的情况下，则需要关注报表平台型产品。报表平台是指提供报表、统计图及其他 BI 组件（仪表盘、数据看板等）的组织管理、权限控制等功能的软件系统，重点是功能全面的系统。

在报表行业，厂商提供的产品也大体分为这两类：以中间件形式提交的报表工具和以报表为中心的外围解决方案即报表平台。选择报表软件时，一定先要搞清备选产品是哪一类的，和需求目标不匹配的，做得再炫也不必考虑了。

报表工具

报表工具是细分领域“专而精”的产物，主要解决固定报表的制作。所谓固定报表，是指由技术人员预先定义好取数规则，运算逻辑的报表，后台会有一些较复杂的运算；业务人员只在 web 端查看或简单的增删改数据，不涉及报表结构的修改。固定报表是日常报表开发工作中最常用且工作量最大的报表形式。而对应的，另一种报表形式，自助报表，可由业务人员在 web 端自由拖拽指标字段生成不预先定义好表结构的报表，它能应对一些临时性的简单查询需求。这两种形式从目标用户到应用方式两者都有巨大不同，在选型时一定把固定报表和自助报表分开考虑。本节先针对固定报表提供一些考察点，自助报表的问题在后面的章节会介绍。

表格布局

目前国内主流报表工具采用的表格布局都是类 Excel 的单元格式，其好处是绘制简单方便。而有些早期产品以及国外产品仍采用控件拖拽式布局，就很不好用，绘制带有合并格的复杂格式报表非常繁琐。而且，采用类 Excel 式布局的产品一般都能导入以前用 Excel 画的表，也可以不失真地将报表导出成 Excel，这都是控件式布局产品很难实现的但却非常必要的功能。

复杂报表

报表工具的主要任务就是减少开发工作量，而复杂报表是工作量的重头。

对于报表样式简单，数据来源单一的简单报表，如图 1。几乎所有的报表工具都可以轻松实现（毕竟一个成熟的工具，要是连这样的简单报表都搞不定，也就没啥存在的意义了），没有区分度。但有些报表样式复杂，数据来源多样，统计口径不规则的复杂报表，就不是每家报表工具都容易做出来的了。如图 2，用国外或开源的报表工具就很难做出来，代码量相当大，完全起不到减轻开发工作量的目的。相比之下，采用了非线性报表模型的国产报表工具对付复杂报表的能力要强大得多，报表工具可能是少有的几个国产软件远胜国外软件的企业软件领域了。不过，不同产品在模型细节的支持程度并不一致，还需要针对项目中的复杂报表仔细验证，弄不好工作进程就可能被一两个特别麻烦的报表给卡住。重点的考察模型功能有：多源关联分片、行称是否对称、跨行组的同比环比以及排名计算、重叠分组等不规则分组方案、动态分组层次等。

图 1

图 2

多数据源

报表工具也应该与时俱进，支持多样性数据源，信息化应用越来越广泛了，ERP、CRM、OA、BPM 等系统各种上马，企业数据越来越大，报表也通常需要取到多个数据库多个数据表的数据，所以最直接也是效果最好的，就是报表工具直接支持多数据源关联，而不是先 ETL 做数据仓库等工作之后再取数。

集成性

方便易用的集成性是报表工具的重要指标，也是特别容易在选型时被忽略的指标。有些报表工具（特别是国外的产品）功能很强大，独立使用也是六六六，但在国内跟各个业务系统集成的整体氛围下就水土不服，因为缺失集成性。方便易用的集成性要求报表工具能对应用程序提供友好全面的接口，方便用户与各业务系统无缝对接。能够适应各种环境，能以类库方式完全集成到应用系统中。这样不仅可以提高报表获取数据时与应用系统数据交互的性能，还可以利用服务器的负载均衡等能力提升用户体验。

开放性

灵活的开放性才能适应用户更多特殊的需求，不管是集成商还是终端用户都可以通过丰富的 API 接口，全面地对报表应用进行各种操作，以需要的方式灵活地使用报表。满足用户各种个性化需求的自定义。

性能与容量

决定报表工具生死的往往是性能和容量指标。随着大数据时代的到来，选择报表工具时，性能指标越来越被用户所关注。网络，报表层等都可能成为性能瓶颈。而一款好的报表工具应该尽量绕开可以避免的瓶颈，如报表层就有很大的优化空间。对于报表内常用的多数据源对齐，排名等采用更高性能的 Hash 算法。报表提供缓存机制，包括模板缓存、结果缓存、分页缓存等多种方式，提升报表服务器性能。提供集群缓存同步机制，实现负载均衡的服务器之间跳转访问时的缓存自动同步。

移动端

现在，越来越多的用户想在移动端随时随地查看企业报表，第一时间掌握企业动态。他们往往是拿来主义，要求报表中间件厂商提供完整的移动端 APP 供他们直接使用。但其实这是一个误区，对于移动端 APP 往往是由系统集成商开发并在提供给用户时，适当的做一些客户定制化的功能。而报表只需要具备输出 HTML5 的能力，支持在移动端输出即可。作为中间件应用时，报表工具厂商直接提供的 APP 是没有意义的，没有必要去考察。

美观性

看似重要的美观性其实跟报表工具的直接关系不大。图表是用来直观的展示数据，方便管理者在纷杂的数据中快速判断出业务数据的分布、趋势、占比、同比、环比等变化规律，支持管理者决策。图表类型的数量及是否支持钻取、联动等功能也是评估报表工具的指标之一。美观性对于报表当然很重要，但由于有众多开源图形技术，这方面的比拼就已经不再是报表工具的重点了，报表工具厂商与其花时间精力去追赶，不如直接把好的东西为我所用，这就又回到了“专而精”的话题。所以与其用美观性衡量报表跟图表，不如衡量报表工具对第三方图表的集成性更实际。

价格

最后，但不是最不重要的是报表工具的价格。不过考察产品价格时要同时考察后续报表开发制作的成本，要对比实际拥有成本。比如开源的工具虽然没有购买成本，但实现复杂报表时，背后需要付出很大的工作量，在核算成本时往往是入不敷出，实际拥有成本更高。

报表平台

报表平台应该包括的基本功能包括：报表资源管理、用户管理、数据管理、权限管理、系统外观及报表样式管理、定时调度任务管理以及系统监控等；移动应用，流程填报，也是报表平台必不可少的功能；还有安全机制，运行报表平台时不安装插件、不改变用户的安全设置，这样才对用户是安全的。这些报表平台的常规功能基本每家厂商都具备，用户在考察这些内容时也很少有认知误区，一般不会踩雷，我们就不细说了。这里只介绍一些容易被忽略的功能点。

整合能力

不同企业，功能需求也是千差万别的，即使功能再全面的一款报表平台软件，也逃不开个性化行业定制以及跟现有系统的整合。对于报表平台的集成，主要考虑是否提供相关二次开发接口，可以修改系统风格样式以匹配现有业务系统，是否提供多种单点登录接口，可以使用现有业务系统的组织机构权限机制等。

可组装性

要求平台中的各个功能模块低耦合，可以像积木一样随意拆装。 这样“报表 + 的功能太多了，有很多我都不需要，或者我预算有限，买不起这么多功能怎么办？“的顾虑就可以很愉快的解决了。

后续开发方案

报表业务有天生的不稳定性，导致报表总是没完没了地要修改和新增，不可能一次性做完。那么问题来了：如果有新的报表需求或者原有报表的维护工作由谁负责？厂商？集成商？用户？这个一定要在选型时就考虑清楚这个问题，不然很容易被项目后期维护费用惊到或者出现报表平台不能真正用起来的情况。这里要强调一下，不要寄希望于自助报表（后面会讲到原因）。

交付方式

对于报表平台类产品，有两种交付方式，即产品交付和项目交付。而项目交付，定制解决方案，为平台类产品的主要交付方式。在当下大环境下，IT 实施团队的选型已经成为企业信息化建设成败的关键。但国内供应商不少是报表工具厂商扩大业务而形成的，产品本身还可以，但项目经验少，管理能力弱，所以需要考察的就不仅仅是报表软件的功能点，更多是的要考察做实施项目团队的技术能力，相关行业经验以及项目管理体系和质量。而国外的供应商实施能力就更弱了，可能是由于国外定制服务成本高导致的吧，在缺乏市场定制化解决方案的需求的前提下，缺乏集成性，难以适应国内需求。

自助报表

最后我们来谈一下自助报表。

自助报表也是近年内特别热门的需求，几乎所有的报表平台都提供有这个功能，各大厂商纷纷宣称可以让业务人员拖拽制表，不需要技术人员参与了。

但这里有个巨大的误区。目前市场上的自助报表（或交互式 BI）虽然可以在页面上轻松实现钻取、切片、旋转、分页、自定义指标、排序、各种基本计算（求和，求平均，最大最小值等），与此同时兼具页面友好美观，使用流畅等特点。但是，自助报表能够解决的业务人员需求其实相当少，例如自助报表完全解决不了过程性计算，而大多数报表都需要过程计算来准备数据，比如报表数据模型支持多源运算就是过程计算的一种。不支持关联查询的自助报表，一般只能解决 10% 的业务人员需求，即使有了关联查询也只能解决 20% 到 30%。所以不能对自助报表的期望过高。

关联查询是绝大多数自助报表产品都不支持的能力。所谓关联查询就是需要查询的数据不在数据库的一张物理表中，通过某个主外键关系关联才能获得需要的信息，例如：查询存储金额在 10 万以上的本地储户信息，就需要做多个表的关联运算。传统自助报表不支持关联查询，需要事先建立逻辑或物理宽表把表间关系做死，一旦关联需要发生变化时，只能重新建模，但这就要求有 IT 人员再次参与，业务人员的自助就失去意义了，而这个功能缺失又很可能被炫酷的界面掩盖而被忽略。能否支持关联查询是是考察自助报表功能的关键指标。

有些报表工具也提供自助报表的能力，也可以作为报表中间件的功能组件被集成，这时候就要考察其可集成的能力，即也能像报表中间件一样集成到其他应用系统中使用。如果有集成需求，则要重点考察这方面的能力。