“填”并不重要

填報功能是國內報表工具的一個重要特色。國外的報表工具的英文名稱是report，完全沒有填的意思，而且報表被歸為BI類產品，講究的是事后分析，也不會管數據的錄入。但在國內，報表則天然被認為有填寫的功能，即使有強烈BI色彩的報表平臺，也需要支持填報功能也方便補錄數據。

考察報表工具的填報功能時，用戶常常會注重“填”，也就是看產品提供了多少種編輯組件，這其實是個誤區。

把表格作為一個整體來輸入數據時，并不需要太多的編輯風格，大家可以看看Excel提供了多少種、有多少人叫嚷過不夠用?如果希望把填寫功能用于任何輸入界面時，那確實需要豐富的編輯風格，但這種場景同時還要求填寫組件開放足夠的事件方法以便進一步細致控制，而這對于一次要處理N多單元格的報表來說就太麻煩了，以致于用戶也懶得學。填報表并不適合用于所有界面輸入的場景。

入庫是關鍵

填報功能需要重點考慮的應當是“報”，更明確地說，是解決單元格值與數據存儲之間的映射。

顯然，數據填寫上來本身并不是目的，用戶還要對這些數據進行計算分析，那么表格內數據就必須進入一個開放的可計算的存儲體系中。最常見的情況就是數據庫了，所以也可以把這個動作稱為“入庫”，具體來講就是要拆分出單元格值寫入合適的數據庫表中。有些填報方案只管填寫上傳而不管入庫，填出的表格是一團不可拆分的東西，這就把用戶帶進了坑，數據不可利用，還要投入大量成本再雇傭程序員進行解析入庫，有時因格式不公開還只能繼續找該廠商人員。這是考察填報功能時特別要注意的問題。

那么，填報方案設計了入庫功能是否就可以了?那還不夠，對于單元格值與數據存儲的映射，還需要考察如下三個方面的能力：

有來有去：入庫是指填寫的數據有去向，而填報表中的數據在填寫前常常并不是空格子，它首先還要有個來源，填寫過程中改寫后再入庫;

來去無關：來源和去向不一定是相同，有可能從某些數據匯總出來的中間結果，補錄或修改數據后再寫入另一個地方，這普遍發生在多級上報的場景中;

一來多去：來源當然只能是一個，但同一套數據卻可能需要寫入多個目標存儲體系中(不同的數據庫表中);

一般來說，這三方面都考慮到了，且使用較為便捷的填報方案就是不錯的了。

技術型?業務型?

話還沒說完。

我們知道，關系數據庫的表結構需要專業技術人員來設計，如果使用數據庫作為填報表的數據存儲體系，那么也需要程序人員來設計表格與數據庫的映射。換句話說，填報表必須用技術人員制作，可以說成是“技術型填報”。這也是當前業界中可用的填報工具的主要形式。

但現實并不是這么簡單。

補錄數據常常是業務部門發起的，如果每件事都找技術人員協助，效率必然很低。而且，有時候出于安全要求，業務部門不想讓其它人員看到填寫的數據甚至表格。用戶希望開發人員一次性做好應用系統后就不需要再參與運行過程了。

這需要填報工具提供“業務型填報”能力，也就是讓業務人員能夠自己繪制填報表。畫表本身是不難的，有Excel使用基礎的人都能做到，但業務人員不會設計數據庫表結構，更不會在庫中創建和維護數據表。

這時候就不能采用關系數據庫作為存儲體系了。填報工具需要有兩方面的能力：一方面能根據用戶畫的表格自動識別出合理的數據結構，這樣就可以把數據結構化后寫入某種格式的文件中;另一方面要提供針對結構化文件的計算處理能力，相當于取代數據庫來實現后續計算，仍然是一種開放的可計算的存儲體系，但并不一定是數據庫。這樣，開發人員只要一次性地把用戶角色、上報控制及統計范圍等在應用中做好，以后再新增或修改填報表以及針對填寫數據的統計查詢都可以由業務人員自己完成了。

潤乾怎么處理?

業務型填報的兩個問題都不簡單，不過我們都已經有了辦法。

對于問題二，潤乾有現成方案，我們開發了集算器產品，可以不依賴于數據庫實現更強大的計算能力，再配有交互式的界面，可以由業務人員自由地完成豐富的統計分析。

對于問題一，我們在新潤乾報表5中提供了自動識別數據結構的方案。用戶用類似Excel的方法繪制表格，再指定某些單元格的類型，即哪些單元格是用于分類的(維度類)，哪些單元格是用于填寫的(數值格)，根據這些程序就能基本正確地分析出合理的數據結構。

比如下表:

設置B3,B10,C10-D13等格是用于分類的維度格，C3-G7,D10-G13等格是用于填寫的數值格，程序將能自動識別出來兩組數據結構及記錄字段對應的單元格。

對于用戶來講，指定單元格類型是個關鍵步驟，但難度并不算大，本來和業務知識相關性強，再通過一些例子訓練也都能掌握。

上面例子中的表格并不是單一數據結構的簡單行式表，這里有不止一個數據結構，程序也可以正確地識別出來，并找出合適的屬性(字段)名稱。