“填”并不重要
填报功能是国内报表工具的一个重要特色。国外的报表工具的英文名称是report，完全没有填的意思，而且报表被归为BI类产品，讲究的是事后分析，也不会管数据的录入。但在国内，报表则天然被认为有填写的功能，即使有强烈BI色彩的报表平台，也需要支持填报功能也方便补录数据。
考察报表工具的填报功能时，用户常常会注重“填”，也就是看产品提供了多少种编辑组件，这其实是个误区。
把表格作为一个整体来输入数据时，并不需要太多的编辑风格，大家可以看看Excel提供了多少种、有多少人叫嚷过不够用?如果希望把填写功能用于任何输入界面时，那确实需要丰富的编辑风格，但这种场景同时还要求填写组件开放足够的事件方法以便进一步细致控制，而这对于一次要处理N多单元格的报表来说就太麻烦了，以致于用户也懒得学。填报表并不适合用于所有界面输入的场景。
入库是关键
填报功能需要重点考虑的应当是“报”，更明确地说，是解决单元格值与数据存储之间的映射。
显然，数据填写上来本身并不是目的，用户还要对这些数据进行计算分析，那么表格内数据就必须进入一个开放的可计算的存储体系中。最常见的情况就是数据库了，所以也可以把这个动作称为“入库”，具体来讲就是要拆分出单元格值写入合适的数据库表中。有些填报方案只管填写上传而不管入库，填出的表格是一团不可拆分的东西，这就把用户带进了坑，数据不可利用，还要投入大量成本再雇佣程序员进行解析入库，有时因格式不公开还只能继续找该厂商人员。这是考察填报功能时特别要注意的问题。
那么，填报方案设计了入库功能是否就可以了?那还不够，对于单元格值与数据存储的映射，还需要考察如下三个方面的能力：
有来有去：入库是指填写的数据有去向，而填报表中的数据在填写前常常并不是空格子，它首先还要有个来源，填写过程中改写后再入库;
来去无关：来源和去向不一定是相同，有可能从某些数据汇总出来的中间结果，补录或修改数据后再写入另一个地方，这普遍发生在多级上报的场景中;
一来多去：来源当然只能是一个，但同一套数据却可能需要写入多个目标存储体系中(不同的数据库表中);
一般来说，这三方面都考虑到了，且使用较为便捷的填报方案就是不错的了。
技术型?业务型?
话还没说完。
我们知道，关系数据库的表结构需要专业技术人员来设计，如果使用数据库作为填报表的数据存储体系，那么也需要程序人员来设计表格与数据库的映射。换句话说，填报表必须用技术人员制作，可以说成是“技术型填报”。这也是当前业界中可用的填报工具的主要形式。
但现实并不是这么简单。
补录数据常常是业务部门发起的，如果每件事都找技术人员协助，效率必然很低。而且，有时候出于安全要求，业务部门不想让其它人员看到填写的数据甚至表格。用户希望开发人员一次性做好应用系统后就不需要再参与运行过程了。
这需要填报工具提供“业务型填报”能力，也就是让业务人员能够自己绘制填报表。画表本身是不难的，有Excel使用基础的人都能做到，但业务人员不会设计数据库表结构，更不会在库中创建和维护数据表。
这时候就不能采用关系数据库作为存储体系了。填报工具需要有两方面的能力：一方面能根据用户画的表格自动识别出合理的数据结构，这样就可以把数据结构化后写入某种格式的文件中;另一方面要提供针对结构化文件的计算处理能力，相当于取代数据库来实现后续计算，仍然是一种开放的可计算的存储体系，但并不一定是数据库。这样，开发人员只要一次性地把用户角色、上报控制及统计范围等在应用中做好，以后再新增或修改填报表以及针对填写数据的统计查询都可以由业务人员自己完成了。
润乾怎么处理?
业务型填报的两个问题都不简单，不过我们都已经有了办法。
对于问题二，润乾有现成方案，我们开发了集算器产品，可以不依赖于数据库实现更强大的计算能力，再配有交互式的界面，可以由业务人员自由地完成丰富的统计分析。
对于问题一，我们在新润乾报表5中提供了自动识别数据结构的方案。用户用类似Excel的方法绘制表格，再指定某些单元格的类型，即哪些单元格是用于分类的(维度类)，哪些单元格是用于填写的(数值格)，根据这些程序就能基本正确地分析出合理的数据结构。
比如下表:
设置B3,B10,C10-D13等格是用于分类的维度格，C3-G7,D10-G13等格是用于填写的数值格，程序将能自动识别出来两组数据结构及记录字段对应的单元格。
对于用户来讲，指定单元格类型是个关键步骤，但难度并不算大，本来和业务知识相关性强，再通过一些例子训练也都能掌握。
上面例子中的表格并不是单一数据结构的简单行式表，这里有不止一个数据结构，程序也可以正确地识别出来，并找出合适的属性(字段)名称。
