文录通方案介绍
（一）业务痛点
目前，市场上存在一类围绕文档数据录入的需求，比如合同，检测报告，电子病历，检查表单，政府红头文件等，此类文档繁多，对格式要求严格，对数据正确性要求严格。而传统的解决方案不能很好的支持这一需求，表现在如下几个方面：
一，一种解决方案是：围绕固定格式的文档模板定制化开发一套界面进行数据录入。该解决方案针对1000份格式不同的文档就需要开发1000套对应格式的界面，可想而知，该方案不适用于解决格式不同且数量繁多的文档数据录入问题。
二，另一种解决方案是：类似报表设计工具，先用工具设计一种格式的报表模板，然后，将数据填充到模板中获得最终文档。该解决方案受限于报表设计工具的能力，其设计出的文档格式弱于word或者excel的文档格式。
三，文档数据电子化之后，后续基于文档数据做分析，需要再次围绕文档格式开发对应的文档数据提取程序，类似定制化数据录入界面，针对1000份格式不同的文
档就需要开发1000套对应格式的数据提取程序，不具备普适性。
四，文档数据不能实时交互，表现在：
缺少文档与系统之间的数据交互，比如：完成一份每日检查表单，表单中的数据信息不能够比较快的推送到后端数据分析系统。
缺少文档与文档之间的数据交互，比如：签订A+B两份关联合同，A合同中的数据在签订时不能够比较快的反馈给合同B。
五，文档数据不能协同录入与变更追踪，表现在：
缺少文档从线上录入数据转入线下录入数据的能力。
缺少多人对同一份文档的不同部分进行数据录入的能力。
缺少查询文档数据历史上由哪个数据变更为哪个数据的留痕信息。
为此，亟需研究一种围绕文档数据录入的新型解决方案。
（二）方案介绍
之所以存在以上痛点，本方案认为问题聚焦于“文档”这一对象，必须改变“文档”对象的组成结构，才能从根本上化解以上问题。
而传统的解决思路是以系统为中心出发进行设计，文档仅作为系统的附属品。这种构思方式不可避免的陷入系统应用所属的业务领域中，难以形成围绕文档数据录入的公共产品或者服务。
本方案中，以文档为中心出发进行设计，先梳理有关文档数据录入的所有业务需求，对具体的业务需求进行归类抽象，从而获取围绕文档数据录入的公共业务。具体为：
犹如对数据库表操作的基本行为有：增，删，改，查四种。本方案针对文档进行数据录入的基本行为分析如下：
关于“增”，实际上是基于模板进行数据的首次录入；
关于“删”，本方案做了特别研究，认为：该行为属于文档编辑排版领域，不属于文档数据录入领域，在文档数
据录入领域，都是基于模板进行数据填充，模板的原始内容是不允许变更的，因此不存在“删”这一行为。
关于“改”，实际上是基于模板进行数据的重复录入；
关于“查”，本方案做了特别研究，认为：文档电子化后，“查”是基于文档类别进行的，本质是把查出的文档集合中的数据提取出来，做进一步分析用，所以文档提供的基本行为应该是：提取。
结论：针对文档进行数据录入的基本行为只有：录入，提取。
进一步，本方案梳理了围绕文档的录入数据类型为：文本，表格，图片。其中文本类型更细分如下：整数、小数、字符串、多选项、单选项、日期和时间。
进一步，本方案梳理了这些数据类型在文档数据录入时存在的各种业务约束，比如，整数类型数据录入时，存在最小值，最大值约束等。
进一步，本方案认为在往文档中进行数据录入时，每一个数据值是干净清晰的，倘若在录入数据时候就将数据值捕获并标注一种定位方式，那么后期不再需要根据文档格式编写数据提取程序，同时，这种定位方式构成了每一
份文档中具体数据项的坐标，坐标为数据在文档与文档之间交互或者文档与系统之间交互奠定了基础。
上述要点构成了文档数据录入问题的公共业务。本方案认为，现有市场上的各类文档之所以不能解决上述痛点问题，在于文档的组成结构中只有数据和格式，而市场上围绕文档的数据录入痛点本质上属于数据的效验和交互业务，倘若还按照传统的问题解决思路把业务交由系统来解决是不可取也是无法适应的。更合适的解决思路是将这些业务转换为一种描述规则，系统解读这种规则并提供对应的行为能力完成围绕文档的数据录入业务。犹如浏览器解释CSS，JS完成对应的网站操作交互，同时，规则可以作为文档组成结构的一部分，如此，围绕具体文档的数据录入业务被内聚到了文档自身的组成结构中。
进一步，围绕文档的操作系统相应划分为两个部分：
前端引擎解析规则动态创建数据录入界面，如此可以解决针对每一份文档编写一套前端界面带来的无法估计的工作量。
后端引擎解析规则对输入数据进行效验与格式转换，如此可以保证符合业务规则的数据才能进入文档，保证了
文档数据正确性，同时，后端引擎可以将接收到的数据单独保存并附加定位标注，为文档数据的协同，交互与留痕奠定技术基础。
本方案在设计落脚点上基于文档数据录入问题的公共业务，不受限于某一特定文档在特定业务领域的应用，在理论上，更具备普适性。
在实践中，本方案的执行方式为以现有成熟文档技术为基础，在其上附加一个业务规则描述，构成本方案给出的新文档。之后，系统以该新文档为基础完成数据录入。
制作文档时，本方案采用现有成熟文档技术已经对外公开的接口实现，因此能做到与手工制作文档100%一致的格式效果，满足了对文档格式存在强要求的问题。
技术架构图如下：
图 1 文档引擎架构
下面以Excel为例，给出本方案应用的一个简要例子：
采用Excel编制的模板：
图 2 文档模板
附加本方案设计的规则：
[Basic]
1=t1|编号|str?自动生成的表单编号
2=t2|时间|date|yyyy年MM月dd日
3=t3|星期|select|星期一-星期一,星期二-星期二,星期三-星期三,星期四-星期四,星期五-星期五,星期六-星期六,星期日-星期日
4=weather|天气|select|晴,多云,小雪
5=l1|检查情况|table|2|3
6=t5|专职安全员|str
7=t6|现场照片|image|3[6,0,6,2,10,30,43,-30|6,2,6,5,50,30,17,-30|6,5,6,7,25,30,50,-30]
[l1]
1=c1|检查部位|str[4-4,1-1]
2=c2|存在问题|text[4-4,2-3]
3=c3|处理情况|text[4-4,4-7]
*=[3,0]
接收约定格式的数据：
{
"t1": "001",
"t2": 1642056195,
"t3": "星期四",
"weather": "晴",
"l1": [{
"c1": "检查部位样例数据1",
"c2": "存在问题样例数据1",
"c3": "处理情况样例数据1"
},
{
"c1": "检查部位样例数据2",
"c2": "存在问题样例数据2",
"c3": "处理情况样例数据2"
},
{
"c1": "检查部位样例数据3",
"c2": "存在问题样例数据3",
"c3": "处理情况样例数据3"
}
],
"t5": "张三",
"t6": "img1,img2"
}
制作的文档效果：
图 3 文档效果
（三）方案价值
基于本方案包装出来的新文档，有以下几方面的价值：
第一步，可以包装为一个文档制作组件，对于开发人员，只要按照约定的格式组织数据，即可通过该组件生成对应格式的文档，节约开发者的开发成本。
进一步，可以包装为一个服务，统一管理文档模板，对于外部应用只要按照约定的格式组织数据，即可调用该服务获取服务制作好的文档，节约开发者的开发成本。
更进一步，可以包装为一个文档服务产品，类似OFFICE，金山文档等，对外出售。
（四）方案优势
支持采用统一模式制作不同类型文档。
快速支持任意类型任意格式文档的电子化。
低学习成本。
（五）方案劣势
受限于现有成熟文档对外公开技术接口的完善度。
（六）应用目标对象
已经拥有大量制式文档，要求保持原文档的格式且对文档电子化有需求的组织，分为三类：
一，以文档作为交付产品。如：出具检测报告的研究院，提供电子病历的医院等；
二，对文档数字化建设有要求的企业，比如，签订合同时，希望合同一旦审批，相关数据即可推送到企业财务系统；
三，全行业存在的各类检查表单在移动端的快速支持，比如，建筑工地的每日例行检查表单。
