CN116187942A - 电子合同生成系统、方法、设备及程序产品 - Google Patents

Abstract

本申请实施例提供一种电子合同生成系统、方法、设备及程序产品。在本申请实施例中，通过预先配置不同类型的多个合同模板，在有签署需求的情况下，可以针对与签署需求适配的多个合同模板发起签署操作并提供需要填充到合同模板中的数据；在发起签署操作时，指定对多个合同模板进行合并，对于一个签署方需要同时签署多份电子合同的情况，无需对多份电子合同模板重复的执行发起签署操作；并且在发起签署操作时，可以根据具体需求对预先配置的多种合同模板全部或部分任意合并，无需重复创建合同模板，有助于简化操作流程，提升效率。

Description

电子合同生成系统、方法、设备及程序产品

技术领域

本申请涉及计算机技术领域，尤其涉及一种电子合同生成系统、方法、设备及程序产品。

背景技术

随着互联网技术、电子商务经济的迅猛发展，促使电子化办公逐渐在企业办公方式中占据主导地位，电子合同作为一种在线签发合同的工具和手段，它的实时签署最大幅度压缩了签署成本，因此，电子合同越发广泛应用到企业当中。

在现有的电子合同签署场景中，例如员工入职签署场景，由公司人事部起草电子合同模板，以针对指定的入职员工发起电子合同签署操作。通常，人事部在发起电子合同签署操作时，通过选择任一合同模板指定入职员工进行合同签署。然而，对于需要选择多份电子合同并指定多个员工分别进行合同签署时，这种操作方式较为繁琐，效率较低。

发明内容

本申请的多个方面提供一种电子合同生成系统、方法、设备及程序产品，用以对电子合同的操作流程，提升工作效率。

本申请实施例提供一种电子合同生成系统，包括：请求端和处理端；所述请求端，用于向所述处理端发起处理请求，将多个合同模板及需要填充的合同数据发送所述处理端，以及接收所述处理端返回的目标电子合同，所述目标电子合同是所述处理端对所述多个合同模板按序合并及数据填充后得到的；所述处理端，用于接收所述多个合同模板及所述合同数据；确定所述合同数据在所述多个合同模板中分别对应的填充位置并分别填充至对应的位置；对填充后的多个合同模板按序合并以及修改对应的页码信息，以得到目标电子合同，并将所述目标电子合同返回所述请求端。

在一可选实施例中，所述请求端在向所述处理端发起处理请求之前，还用于：创建多个合同模板并分别设置模板信息，所述模板信息包括固定的常规条款文本和可编辑的控件及控件属性；其中，所述控件属性包括每个控件的标识信息、类型信息和样式信息，以及在每个合同模板中的坐标信息和页码信息，所述类型信息包括用于签署身份信息的签署控件和用于填充指定信息的文本控件。

在一可选实施例中，所述合同数据包括每个合同模板中的控件分别对应的标识信息和文本值，所述处理端在确定所述合同数据在所述多个合同模板中分别对应的填充位置时，用于：识别每个合同模板中各控件分别对应的标识信息、页码信息及坐标信息；根据所述合同数据和每个合同模板中各控件的标识信息，确定每个合同模板中需要填充数据的目标控件，以及所述合同数据中待填充的目标文本值；根据所述目标控件的页码信息和坐标信息，将所述目标文本值填充到所述目标控件对应的文本域中。

在一可选实施例中，所述签署控件的控件属性还包括签署方类型，所述处理端在将所述目标文本值填充到所述目标控件对应的文本域中时，用于：根据每个合同模板中签署控件的签署方类型，确定所述多个合同模板共同对应的签署方类型；根据预存的用户数据，确定预设用户中的用户类型与所述多个合同模板共同对应的签署方类型是否匹配；在确定匹配的情况下，将所述合同数据中对应签署控件的目标文本值对应的填充到每个合同模板中目标签署控件的文本域中。

在一可选实施例中，所述文本控件的控件属性还包括填充类型，所述填充类型包括必填类型和非必填类型，所述处理端在将所述目标文本值填充到所述目标控件对应的文本域中时，用于：根据每个合同模板中文本控件的填充类型，确定为必填类型的目标文本控件；根据所述合同数据和所述目标文本控件的标识信息，确定所述合同数据中是否存在与所述目标文本控件对应的文本值；在确定存在的情况下，将所述合同数据中对应各文本控件的文本值对应的填充到每个合同模板的文本控件的文本域中。

在一可选实施例中，在确定所述用户类型与所述多个合同模板共同对应的签署方类型不匹配和/或所述合同数据中不存在与所述目标文本控件对应的文本值的情况下，所述处理端，还用于向所述请求端返回处理失败的提示信息。

在一可选实施例中，所述请求端，还用于向所述处理端发送合并指示信息，所述合并指示信息用于指示所述处理端对所述多个合同模板全部或部分按序合并。

在一可选实施例中，所述处理端在对填充后的多个合同模板按序合并时，用于：根据所述合并指示信息，确定需要合并的多个目标合同模板；按照所述请求端发送所述多个合同模板的顺序，将填充后的所述多个目标合同模板按序合并。

在一可选实施例中，所述处理端在修改页码信息时，用于：根据所述多个目标合同模板分别包括的页码数，计算每个目标合同模板的每一页以及每一页中的控件对应的页码偏移量；根据所述页码偏移量，对合并后多个目标合同模板的页码数以及每一页中的控件对应的页码信息进行修改。

本申请实施例还提供一种电子合同生成方法，包括：获取多个合同模板及需要填充的合同数据，所述合同数据包括每个合同模板中的控件分别对应的标识信息和文本值；识别每个合同模板中各控件分别对应的标识信息、页码信息及坐标信息；根据所述合同数据和每个合同模板中各控件的标识信息，确定每个合同模板中需要填充数据的目标控件，以及所述合同数据中待填充的目标文本值；根据所述目标控件的页码信息和坐标信息，将所述目标文本值填充到所述目标控件对应的文本域中；将填充后的所述多个合同模板按序合并以及修改对应的页码信息，以得到目标电子合同。

在一可选实施例中，所述控件包括用于签署身份信息的签署控件和用于填充指定信息的文本控件，所述签署控件的控件属性包括签署方类型，将所述目标文本值填充到所述目标控件对应的文本域中，包括：根据每个合同模板中签署控件的签署方类型，确定所述多个合同模板共同对应的签署方类型；根据预存的用户数据，确定预设用户中的用户类型与所述多个合同模板共同对应的签署方类型是否匹配；在确定匹配的情况下，将所述合同数据中对应签署控件的目标文本值对应的填充到每个合同模板中目标签署控件的文本域中。

在一可选实施例中，所述文本控件的控件属性包括填充类型，所述填充类型包括必填类型和非必填类型，将所述目标文本值填充到所述目标控件对应的文本域中，包括：根据每个合同模板中文本控件的填充类型，确定为必填类型的目标文本控件；根据所述合同数据和所述目标文本控件的标识信息，确定所述合同数据中是否存在与所述目标文本控件对应的文本值；在确定存在的情况下，将所述合同数据中对应各文本控件的文本值对应的填充到每个合同模板的文本控件的文本域中。

在一可选实施例中，在确定所述用户类型与所述多个合同模板共同对应的签署方类型不匹配和/或所述合同数据中不存在与所述目标文本控件对应的文本值的情况下，所述方法还包括输出处理失败的提示信息。

本申请实施例还提供一种电子合同生成装置，包括：获取模块、处理模块和确定模块；所述获取模块，用于获取多个合同模板及需要填充的合同数据，所述合同数据包括每个合同模板中的控件分别对应的标识信息和文本值；所述处理模块，用于识别每个合同模板中各控件分别对应的标识信息、页码信息及坐标信息；所述确定模块，用于根据所述合同数据和每个合同模板中各控件的标识信息，确定每个合同模板中需要填充数据的目标控件，以及所述合同数据中待填充的目标文本值；所述处理模块，还用于根据所述目标控件的页码信息和坐标信息，将所述目标文本值填充到所述目标控件对应的文本域中；将填充后的所述多个合同模板按序合并以及修改对应的页码信息，以得到目标电子合同。

本申请实施例还提供一种计算机设备，包括：处理器和存储器，在所述处理器执行计算机程序时，用于实现所述电子合同生成方法。

本申请实施例还提供一种计算机程序产品，包括计算机程序/指令，当所述计算机程序/指令被处理器执行时，用于实现所述电子合同生成方法。

在本申请实施例中，通过预先配置不同类型的多个合同模板，在有签署需求的情况下，可以针对与签署需求适配的多个合同模板发起签署操作并提供需要填充到合同模板中的数据；在发起签署操作时，指定对多个合同模板进行合并，对于一个签署方需要同时签署多份电子合同的情况，无需对多份电子合同模板重复的执行发起签署操作；并且在发起签署操作时，可以根据具体需求对预先配置的多种合同模板全部或部分任意合并，无需重复创建合同模板，有助于简化操作流程，提升效率。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1a为本申请实施例提供的一种电子合同生成系统的结构示意图；

图1b为本申请实施例提供的一种用于设置合同模板信息的操作页面示意图；

图1c为本申请实施例提供的一种用户数据中用户类型与合同模板中签署方类型匹配的示意图；

图1d为本申请实施例提供的一种用户数据中用户类型与合同模板中签署方类型不匹配的示意图；

图1e为本申请实施例提供的一种对合同模板填充数据及合并的示意图；

图2为本申请实施例提供一种电子合同生成方法的流程图；

图3为本申请实施例提供的一种电子合同生成装置的结构示意图；

图4为本申请实施例提供的一种计算机设备的结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

为了简化现有电子合同的操作流程，提升工作效率，本申请实施例提供一种电子合同生成系统，该系统可以实现对多个电子合同模板进行任意组合，以根据不同的签署场景，生成对应的电子合同组合模板。可选地，不同签署场景对应的电子合同组合模板中的类型和数量可以不同，基于此，在需要指定不同签署场景下的签署方进行签署操作时，可以选择对应的电子合同组合模板发起签署操作，无需在每次发起签署操作时一一选择合同模板，操作简单，效率高。

下面结合附图对本申请实施例提供的电子合同生成系统进行详细说明。

图1a为本申请实施例提供的电子合同生成系统的结构示意图，如图1a所示，系统包括请求端10和处理端20，在本申请实施例中，不限定请求端10和处理端20之间的关联关系，可选地，请求端10和处理端20可以位于同一局域网内，也可以分别属于不同但可以互相通信的网络。进一步，本申请实施例也不限定请求端10和处理端20的实现形态，可选地，请求端10和处理端20可以是两个相互独立的网站、服务器设备或终端设备中的任一种，也可以是属于同一网站、服务器设备或终端设备中的两个不同模块，具体可以根据实际需求确定。

在本申请实施例中，以请求端10和处理端20分别为两个独立的服务器设备为例进行说明，其中，请求端10可作为起草电子合同模板的设备，用于创建多个合同模板并分别设置模板信息。可选地，模板信息包括固定的常规条款文本和可编辑的控件，例如，在劳动合同中，通常包括劳动法规定的各项条款以及公司的内部规定，劳动法规定的各项条款通常不可编辑，而公司的内部规定可以根据公司的实际情况灵活调整。基于此，操作人员在设置模板信息时，可以将劳动法规定的各项条款设置为固定的常规条款文本，对于可编辑的控件，可以按需设置不同的控件名称，例如，工作时间、岗位职责、薪资数额、居住地址等等，以用于针对不同的职位设置不同的数据。

在本申请实施例中，针对设置模板信息这一功能，请求端10可提供对应的操作页面，操作人员可以通过该操作页面设置每个合同模板对应的模板信息。需要说明的是，本申请实施例不限定该操作页面的具体功能和样式，图1b为一种操作页面的示例形式，如图1b所示，在该操作页面中包括用户创建合同模板的“新建模板”控件，在操作人员触发“新建模板”控件的情况下，可以展示对应的可编辑页面，以用于操作人员编辑模板信息。

在本申请实施例中，为了便于区分和管理，不同场景对应的合同模板样式可以不同，为此，操作人员在设置模板信息时，可以对不同类型的合同模板进行区别设置。可选地，如图1b所示，操作页面上还可以包括“模板类型”控件，在“模板类型”控件被触发的情况下，可以展示多种模板类型，以供操作人员选择所需的模板类型，其中，每种模板类型对应的模板样式不同。

在本申请实施例中，不限定展示多种模板类型的具体方式，根据“模板类型”控件的不同，展示方式可以不同，在一可选实施例中，“模板类型”控件为可选择的下拉列表，其中包括多种模板类型，操作人员可以从中选择任一种模板类型以设置对应的模板信息；在另一可选实施例中，“模板类型”控件为操作按钮，在被触发的情况下可以通过弹窗、浮层、页面跳转等方式展示多种模板类型，以供操作人员从中选择任一种模板类型，当然并不限于此，具体的展示方式可以根据实际需求确定。

进一步可选地，为了简化操流程，每种电子合同对应的常规条款文本可以预置在数据库中，在任一种模板类型被选择的情况下，展示对应的可编辑页面时，可以将被选择的模板类型对应的常规条款文本一同展示在可编辑页面中的预设位置。进一步可选地，在可编辑页面展示时，还可以展示其他默认信息，例如，可以是每种电子合同对应的合同名称以及公司内部的统一说明信息等等，这些信息在展示时可以直接以不可编辑的状态展示，也可在展示后由操作人员按需设置是否为可编辑状态。当然，上述展示的内容和方式仅为示例性说明，在实际应用中并不限于此。

在本申请实施例中，并不限定设置模板信息的具体方式，可选地，在任一种模板类型被选择的情况下，可以在可编辑页面上的预设位置直接展示对应的常规条款文本和可编辑的控件，这些预设位置可以为不变的固定位置，也可以为可变位置，以供操作人员按需调整各项内容的展示位置。进一步可选地，可编辑页面上还可以包括工具栏，其中可提供各种控件，操作人员也可以对默认展示的控件进行替换，以得到符合实际需求的编辑方式。例如，默认展示的控件均为可编辑的文本框控件，而实际合同条款中包括需要签署方从多种选项中选择一个目标选项，例如需要员工从多个工作量标准中选择每个月最低完成的目标工作量，针对这种情况，操作人员可以将对应工作量的文本框控件替换为包括多个单选框的组合控件，以分别设置不同的工作量标准。

基于上述，在模板信息设置完成的情况下，操作人员可以对设置完成的合同模板进行保存，以用于合同签署时使用。相应地，在合同模板被保存时，针对合同模板中的各控件会生成对应的控件属性，可选地，控件属性包括但不限于每个控件的标识信息、类型信息和样式信息，以及在合同模板中的坐标信息和页码信息；其中，类型信息包括用于签署身份信息的签署控件和用于填充指定信息的文本控件，可选地，标识信息可以是每个控件在数据库中的ID，也可以是操作人员编辑控件名称。

基于上述，在有电子合同签署需求的情况下，如图1a所示，请求端10可以向处理端20发起处理请求，将需要签署的多个合同模板及需要填充的合同数据发送处理端20，以及接收处理端20返回的目标电子合同，该电子合同是处理端20将合同数据填充到合同模板中得到的。进一步，如图1a所示，处理端20在接收到合同模板及合同数据的情况下，可以确定合同数据在合同模板中分别对应的填充位置并分别填充至对应的位置，以生成目标电子合同。其中，合同数据可以包括每个合同模板中的控件分别对应的标识信息和文本值，以用于处理端20根据标识信息确定每个合同模板中的目标控件，并把合同数据中对应的文本值填充到各目标控件对应的文本域中。

在实际应用中，不同的签署场景需要签署方签署的电子合同数量和类型可能不同，例如，对于员工入职签署场景，需要员工签署劳动合同、保密协议、社保协议等合同，而对与各企业之间或者个人与企业之间的合作签署场景，根据合作类型的不同，需要签署的合同类型和数量也可能不同，例如，委托合作需要签署委托合同、技术或产品转让需要签署转让合同、技术或产品购买需要签署购买合同、代理合作需要签署代理合同等等。

在本申请实施例中，处理端20在确定合同数据在每个合同模板中分别对应的填充位置时，可以识别每个合同模板中各控件分别对应的标识信息、页码信息及坐标信息等控件属性。基于此，处理端20可以根据合同数据中对应各控件的标识信息和每个合同模板中各控件的标识信息，确定每个合同模板中需要填充数据的目标控件，以及从合同数据中确定与各目标控件对应的各文本值，作为待填充的目标文本值。进一步，根据各目标控件在每个合同模板中的页码信息和坐标信息，可以确定各目标文本值在每个合同模板中的填充位置，进而将各目标文本值分别填充到各目标控件对应的文本域中。

由于在不同的签署场景中，每种电子合同对应的签署方可能不同，因此，在本申请实施例中，签署控件的控件属性还包括签署方类型，以用于在不同的签署场景中供不同类型的签署方签署身份信息。例如，在员工入职签署场景中，对应的签署方类型分别为公司作为甲方，员工作为乙方。又例如，在各企业之间或者个人与企业之间的合作签署场景中，若合作者直接合作，则合作双方对应的签署方类型为甲方和乙方；若需要通过中介等企业进行合作，则签署方还包括作为中介的丙方。相应地，签署方类型的不同，对应的身份信息也会不同，若签署方为个人，则对应的身份信息包括但不限于个人的姓名、身份证号码、手机号码、个人电子签名等信息，若签署方为企业，则对应的身份信息包括但不限于企业的名称、统一社会信用代码、企业电子签章等信息。

基于此，为了确保预设用户具备签署电子合同的资质，处理端20在将各目标文本值分别填充到各目标控件对应的文本域中时，可以根据每个合同模板中各签署控件的签署方类型，确定多个合同模板共同对应的签署方类型，以及根据预存的用户数据，确定预设用户中的用户类型与多个合同模板共同对应的签署方类型是否匹配。基于此，在确定匹配的情况下，处理端20可以将合同数据中对应签署控件的各目标文本值对应的填充到每个合同模板中各目标签署控件的文本域中。例如，对于签署方类型是个人，可以将对应的姓名、身份证号码、手机号码、个人电子签名的图案等信息填充到对应目标签署控件的文本域中；对于签署方类型是企业，可以将对应的公司名称、统一社会信用代码、企业电子签章的图案填充到对应目标签署控件的文本域中。可选地，在身份信息包括个人电子签名和/或企业电子签章的情况下，在填充身份信息时，还可以将个人电子签名、企业电子签章对应的数据信息与填充的合同模板进行绑定，以用于在后续的电子合同使用过程中进行身份识别及验证。

相应地，在确定不匹配的情况下，如图1a所示，处理端20还可以向请求端10返回处理失败的第一提示信息，提示请求端10合同模板对应的签署方类型错误，以供请求端10在修改签署方类型的情况下，再次发起处理请求。

图1c为预设用户中的用户类型与合同模板对应的签署方类型匹配的两种情况。在图1c中的一种示例中，合同模板列表中包一份合同模板，对应的签署方类型分别为甲方和乙方；如图1c所示，若预设用户的用户类型包括可作为甲方和乙方的两种用户类型，则可以确定预设用户中的用户类型与合同模板对应的签署方类型匹配。在图1c中的另一种示例中，合同模板列表中包两份合同模板，其中一份对应的签署方类型分别为甲方和乙方，另一份对应的签署方类型分别为乙方和丙方；基于此，可以确定合同列表中的两份合同模板共同对应的签署方类型包括甲方、乙方和丙方；如图1c所示，若预设用户的用户类型包括可作为甲方、乙方和丙方的三种用户类型，则可以确定预设用户中的用户类型与两份合同模板共同对应的签署方类型匹配。

图1d为预设用户中的用户类型与合同模板对应的签署方类型不匹配的两种情况。在图1d中的一种示例中，合同模板列表中包一份合同模板，对应的签署方类型分别为甲方和乙方；如图1d所示，若预设用户的用户类型只有可作丙方的一种用户类型，则可以确定预设用户中的用户类型与合同模板对应的签署方类型不匹配。在图1d中的另一种示例中，合同模板列表中包三份合同模板，三份合同模板对应的签署方类型分别为甲方、乙方、丙方；基于此，可以确定合同列表中的两份合同模板共同对应的签署方类型包括甲方、乙方和丙方；如图1d所示，若预设用户的用户类型包括可作为甲方和乙方的两种用户类型，则可以确定预设用户中的用户类型与三份合同模板共同对应的签署方类型不匹配。

在实际签署场景中，同一种电子合同对不同类型的签署方要求可能不同，或者，同一类型的签署方在不同的签署场景下对应的职责可能不同，因此，电子合同中可能存在必要信息和非必要信息。例如，在签署方为个人的情况下，签署方的姓名、身份证号码、联系方式等身份信息为必要信息，而身高、体重等信息可能为非必要信息；在签署方为企业的情况下，签署方的名称、机构代码、地址等信息为必要信息，而公司规模、在职人数、经营状态等信息可能为非必要信息。又例如，作为个人的签署方，其对公司的商业秘密负有保密义务，而对于公司的名称、机构代码、注册地址等信息则无需保密，因此，涉及商业秘密的内容则为必要信息，而公司的基本信息则为非必要信息。

基于此，本申请实施例中的文本控件的控件属性还包括填充类型，其中，填充类型包括必填类型和非必填类型。处理端20在将各目标文本值分别填充到各目标控件对应的文本域中时，可以根据每个合同模板中各文本控件的填充类型，确定为必填类型的各目标文本控件。进一步，根据合同数据中对应各文本控件的标识信息和合同模板中各目标文本控件的标识信息，确定合同数据中是否存在与各目标文本控件对应的文本值。

基于此，在确定存在的情况下，说明不会存在漏填必要信息的情况，处理端20可以将合同数据中对应各文本控件的文本值对应的填充到每个合同模板的文本控件的文本域中；在确定任一目标文本控件对应的文本值不存在的情况下，如图1a所示，向请求端10返回处理失败的第二提示信息，提示请求端10缺少必要信息，可选地，可以一并指出缺少的必要信息对应的标识信息，以供请求端10在补充该标识信息对应的文本值的情况下，再次发起处理请求。

在本申请实施例中，不限定请求端10向处理端20发送的合同模板数量，可以为一个或多个，本申请实施例以发送多个合同模板为例进行说明。相应地，在请求端10发送多个合同模板的情况下，一同发送的合同数据为多个合同模板分别对应的合同数据。基于此，处理端20在接收到多个合同模板及对应的合同数据的情况下，可以根据合同数据中对应各控件的标识信息确定每个合同模板中需要填充的目标控件及其对应的页码信息和坐标信息，作为填充位置，以将合同数据中各标识信息对应的文本值分别填充到每个合同模板中各目标控件对应的文本域中，生成目标电子合同。

在本申请实施例中，为了简化处理操作，提升效率，请求端10在向处理端20发送处理请求时，还可以向处理端20发送合并指示信息，以指示处理端20根据指示信息对应的方式对多个合同模板全部或部分进行合并，基于上述，处理端20在对多个合同模板填充合同数据之后，可以对填充后的多个合同模板按序合并。可选地，合并指示信息可以包括待合并的合同模板对应的标识，以用于指示处理端20从多个合同模板中确定待合并的多个目标合同模板并进行合并处理。进一步可选地，合并指示信息还可以包括多个目标合同模板对应的合并顺序，以用于指示处理端20对多个目标合同模板按序合并。

需要说明的是，在合并指示信息不包括合并顺序的情况下，处理端20也可以按照默认顺序对多个目标合同模板进行合并处理，本申请实施例不限定默认顺序的具体实现形式。可选地，请求端10在向处理端20发送多个合同模板时，可以以列表的形式发送，处理端20可以按照每个合同模板在列表中的先后顺序对多个目标合同模板进行合并处理；或者，请求端10也可以依次向处理端20发送多个合同模板，处理端20可以按照接收每个合同模板的先后顺序对多个目标合同模板进行合并处理。

进一步，处理端20在对多个目标合同模板进行合并后，可以修改合并后的多个目标合同模板对应的页面信息，得到目标电子合同，以及将得到的目标电子合同返回请求端10，以供请求端10保存及使用。可选地，处理端20在修改合并后的多个目标合同模板对应的页码信息时，可以根据多个目标合同模板分别包括的页码数，计算每个目标合同模板的每一页以及每一页中的控件对应的页码偏移量。进一步，根据每一页中的控件对应的页码偏移量，对合并后的多个目标合同模板的页码数以及每一页中的控件对应的页码信息进行修改。

图1d为针对两个合同模板进行数据填充及合并的过程示意图，假设请求端10发送的合同模板包括合同模板A和合同模板B，合同模板A的顺序在合同模板B之前。如图1d所示，在初始状态下(处理端20接收到合同模板但未填充合同数据)，合同模板A和合同模板B分别为未填充状态；进一步，在处理端20执行数据填充操作之后，如图1d所示，合同模板A和合同模板B分别被填充合同数据，分别成为已填充状态的电子合同A和电子合同B；进一步，在处理端20执行合并操作之后，如图1d所示，电子合同B被按序追加在电子合同A之后，得到合并后的电子合同。

基于此，处理端20可以根据电子合同A和电子合同B中每一页中的各控件分别在对应的原始页码信息及在合并后的电子合同中的页码信息，计算每一个控件的页码偏移量，并根据计算得到的页码偏移量数分别修改每一个控件在合并后的电子合同中的页码信息，以得到目标电子合同。

需要说明的是，本申请实施例不限定请求端10向处理端20发送的具体信息，可选地，在请求端10和处理端20分别属于不同网络的情况下，请求端10可以针对每一个需要签署的电子合同设置对应的合同编号等相关信息。可选地，为了保证数据同步，请求端10在向处理端20发起处理请求时，还可以将自己内部针对本次需要签署的电子合同对应的合同编号发送给处理端20，以供处理端20作为参照数据保存。当然，请求端10自己内部针对每个电子合同设置的相关信息除了合同编号还可以包括其他信息，具体内容在此不做限定。

基于上述，本申请实施例还提供一种电子合同生成方法，该电子合同生成方法可应用与上述系统中的处理端。图2为该电子合同生成方法的流程图，如图2所示，方法包括：

S1、获取多个合同模板及需要填充的合同数据，合同数据包括每个合同模板中的控件分别对应的标识信息和文本值；

S2、识别每个合同模板中各控件分别对应的标识信息、页码信息及坐标信息；

S3、根据合同数据和每个合同模板中各控件的标识信息，确定每个合同模板中需要填充数据的目标控件，以及合同数据中待填充的目标文本值；

S4、根据目标控件的页码信息和坐标信息，将目标文本值填充到目标控件对应的文本域中；

S5、将填充后的多个合同模板按序合并以及修改对应的页码信息，以得到目标电子合同。

在一可选实施例中，控件包括用于签署身份信息的签署控件和用于填充指定信息的文本控件，签署控件的控件属性包括签署方类型，在将目标文本值填充到目标控件对应的文本域中时，可以根据每个合同模板中签署控件的签署方类型，确定多个合同模板共同对应的签署方类型，以及根据预存的用户数据，确定预设用户中的用户类型与多个合同模板共同对应的签署方类型是否匹配。进一步，在确定匹配的情况下，可以将合同数据中对应签署控件的目标文本值对应的填充到每个合同模板中目标签署控件的文本域中，相应地，在确定不匹配的情况下，可以输出用于提示处理失败的第一提示信息。

在一可选实施例中，文本控件的控件属性包括填充类型，填充类型包括必填类型和非必填类型，在将目标文本值填充到目标控件对应的文本域中时，可以根据每个合同模板中文本控件的填充类型，确定为必填类型的目标文本控件，以及根据合同数据和目标文本控件的标识信息，确定合同数据中是否存在与目标文本控件对应的文本值。进一步，在确定存在的情况下，可以将合同数据中对应各文本控件的文本值对应的填充到每个合同模板的文本控件的文本域中，相应地，在确定不存在的情况下，可以输出用于提示处理失败的第二提示信息。

在本申请实施例中，通过预先配置不同类型的多个合同模板，在有签署需求的情况下，可以针对与签署需求适配的多个合同模板发起签署操作并提供需要填充到合同模板中的数据；在发起签署操作时，指定对多个合同模板进行合并，对于一个签署方需要同时签署多份电子合同的情况，无需对多份电子合同模板重复的执行发起签署操作；并且在发起签署操作时，可以根据具体需求对预先配置的多种合同模板全部或部分任意合并，无需重复创建合同模板，有助于简化操作流程，提升效率。

需要说明的是，关于上述方法步骤的具体实现过程可以参见上述方法实施例，在此不做赘述。所提供方法的各步骤的执行主体均可以是同一设备，或者，该方法也由不同设备作为执行主体。比如，步骤S1至步骤S5的执行主体可以为设备A；又比如，步骤S1的执行主体可以为设备A，步骤S2至步骤S5的执行主体可以为设备B；等等。

另外，在上述实施例及附图中的描述的一些流程中，包含了按照特定顺序出现的多个操作，但是应该清楚了解，这些操作可以不按照其在本文中出现的顺序来执行或并行执行，操作的序号如S1、S2等，仅仅是用于区分开各个不同的操作，序号本身不代表任何的执行顺序。另外，这些流程可以包括更多或更少的操作，并且这些操作可以按顺序执行或并行执行。

需要说明的是，本文中的“第一”、“第二”等描述，是用于区分不同的消息、设备、模块等，不代表先后顺序，也不限定“第一”和“第二”是不同的类型。

基于上述，本申请实施例还提供一种电子合同生成装置。例如电子合同生成装置可实现为通信控制器(Communication Control Unit，CCU)中的虚拟装置，例如应用程序。如图3所示，该电子合同生成装置包获取模块301、处理模块302和确定模块303；其中，获取模块301用于获取多个合同模板及需要填充的合同数据，合同数据包括每个合同模板中的控件分别对应的标识信息和文本值；处理模块302用于识别每个合同模板中各控件分别对应的标识信息、页码信息及坐标信息；确定模块303用于根据合同数据和每个合同模板中各控件的标识信息，确定每个合同模板中需要填充数据的目标控件，以及合同数据中待填充的目标文本值；处理模块302还用于根据目标控件的页码信息和坐标信息，将目标文本值填充到目标控件对应的文本域中，以及将填充后的多个合同模板按序合并以及修改对应的页码信息，以得到目标电子合同。

需要说明的是，关于上述装置中各模块的具体功能和实现过程，可参见上述系统实施例，在此不再赘述。

基于上述，本申请实施例还提供一种计算机设备，图4为计算机设备的结构示意图，如图4所示，计算机设备包括：处理器41以及存储有计算机程序的存储器42；其中，处理器41和存储器42可以是一个或多个。

存储器42，主要用于存储计算机程序，这些计算机程序可被处理器41执行，致使处理器41控制计算机设备实现相应功能、完成相应动作或任务。除了存储计算机程序之外，存储器42还可被配置为存储其它各种数据以支持在计算机设备上的操作。这些数据的示例包括用于在计算机设备上操作的任何应用程序或方法的指令。

存储器42，可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

在本申请实施例中，并不限定处理器41的实现形态，例如可以是但不限于CPU、GPU或MCU等。处理器41可以看作是计算机设备的控制系统，可用于执行存储器42中存储的计算机程序，以控制计算机设备实现相应功能、完成相应动作或任务。值得说明的是，根据计算机设备实现形态以及所处于场景的不同，其所需实现的功能、完成的动作或任务会有所不同；相应地，存储器42中存储的计算机程序也会有所不同，而处理器21执行不同计算机程序可控制计算机设备实现不同的功能、完成不同的动作或任务。

在一些可选实施例中，如图4所示，计算机设备还可包括：显示器43、电源组件44以及通信组件45等其它组件。图4中仅示意性给出部分组件，并不意味着计算机设备只包括图4所示组件，针对不同的应用需求，计算机设备还可以包括其他组件，例如，在存在语音交互需求的情况下，如图4所示，计算机设备还可以包括音频组件46。关于计算机设备可包含的组件，具体可视计算机设备的产品形态而定，在此不做限定。

在本申请实施例中，当处理器41执行存储器42中的计算机程序时，以用于：获取多个合同模板及需要填充的合同数据，合同数据包括每个合同模板中的控件分别对应的标识信息和文本值；识别每个合同模板中各控件分别对应的标识信息、页码信息及坐标信息；根据合同数据和每个合同模板中各控件的标识信息，确定每个合同模板中需要填充数据的目标控件，以及合同数据中待填充的目标文本值；根据目标控件的页码信息和坐标信息，将目标文本值填充到目标控件对应的文本域中；将填充后的多个合同模板按序合并以及修改对应的页码信息，以得到目标电子合同。

在一可选实施例中，控件包括用于签署身份信息的签署控件和用于填充指定信息的文本控件，签署控件的控件属性包括签署方类型，处理器41在将目标文本值填充到目标控件对应的文本域中时，用于：根据每个合同模板中签署控件的签署方类型，确定多个合同模板共同对应的签署方类型，以及根据预存的用户数据，确定预设用户中的用户类型与多个合同模板共同对应的签署方类型是否匹配。

进一步，在确定匹配的情况下，处理器41用于：将合同数据中对应签署控件的目标文本值对应的填充到每个合同模板中目标签署控件的文本域中，相应地，在确定不匹配的情况下，处理器41用于：输出用于提示处理失败的第一提示信息。

在一可选实施例中，文本控件的控件属性包括填充类型，填充类型包括必填类型和非必填类型，处理器41在将目标文本值填充到目标控件对应的文本域中时，用于：根据每个合同模板中文本控件的填充类型，确定为必填类型的目标文本控件，以及根据合同数据和目标文本控件的标识信息，确定合同数据中是否存在与目标文本控件对应的文本值。

进一步，在确定存在的情况下，处理器41用于：将合同数据中对应各文本控件的文本值对应的填充到每个合同模板的文本控件的文本域中，相应地，在确定不存在的情况下，处理器41用于：输出用于提示处理失败的第二提示信息。需要说明的是，关于上述计算机设备中处理器的具体功能，可参见上述系统实施例，在此不再赘述。

相应地，本申请实施例还提供一种计算机程序产品，包括计算机程序/指令，当计算机程序/指令被处理器执行时，用以实现上述方法实施例中可由计算机设备执行的各步骤。

上述实施例中的通信组件被配置为便于通信组件所在设备和其他设备之间有线或无线方式的通信。通信组件所在设备可以接入基于通信标准的无线网络，如WiFi，2G、3G、4G/LTE、5G等移动通信网络，或它们的组合。在一个示例性实施例中，通信组件经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信组件还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。

上述实施例中的显示器包括屏幕，其屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与所述触摸或滑动操作相关的持续时间和压力。

上述实施例中的电源组件，为电源组件所在设备的各种组件提供电力。电源组件可以包括电源管理系统，一个或多个电源，及其他与为电源组件所在设备生成、管理和分配电力相关联的组件。

上述实施例中的音频组件，可被配置为输出和/或输入音频信号。例如，音频组件包括一个麦克风(MIC)，当音频组件所在设备处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器或经由通信组件发送。在一些实施例中，音频组件还包括一个扬声器，用于输出音频信号。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (16)

1.一种电子合同生成系统，其特征在于，包括：请求端和处理端；

所述请求端，用于向所述处理端发起处理请求，将多个合同模板及需要填充的合同数据发送所述处理端，以及接收所述处理端返回的目标电子合同，所述目标电子合同是所述处理端对所述多个合同模板按序合并及数据填充后得到的；

所述处理端，用于接收所述多个合同模板及所述合同数据；确定所述合同数据在所述多个合同模板中分别对应的填充位置并分别填充至对应的位置；对填充后的多个合同模板按序合并以及修改对应的页码信息，以得到目标电子合同，并将所述目标电子合同返回所述请求端。

2.根据权利要求1所述的系统，其特征在于，所述请求端在向所述处理端发起处理请求之前，还用于：

创建多个合同模板并分别设置模板信息，所述模板信息包括固定的常规条款文本和可编辑的控件及控件属性；

其中，所述控件属性包括每个控件的标识信息、类型信息和样式信息，以及在每个合同模板中的坐标信息和页码信息，所述类型信息包括用于签署身份信息的签署控件和用于填充指定信息的文本控件。

3.根据权利要求2所述的系统，其特征在于，所述合同数据包括每个合同模板中的控件分别对应的标识信息和文本值，所述处理端在确定所述合同数据在所述多个合同模板中分别对应的填充位置时，用于：

识别每个合同模板中各控件分别对应的标识信息、页码信息及坐标信息；

根据所述合同数据和每个合同模板中各控件的标识信息，确定每个合同模板中需要填充数据的目标控件，以及所述合同数据中待填充的目标文本值；

根据所述目标控件的页码信息和坐标信息，将所述目标文本值填充到所述目标控件对应的文本域中。

4.根据权利要求3所述的系统，其特征在于，所述签署控件的控件属性还包括签署方类型，所述处理端在将所述目标文本值填充到所述目标控件对应的文本域中时，用于：

根据每个合同模板中签署控件的签署方类型，确定所述多个合同模板共同对应的签署方类型；

根据预存的用户数据，确定预设用户中的用户类型与所述多个合同模板共同对应的签署方类型是否匹配；

在确定匹配的情况下，将所述合同数据中对应签署控件的目标文本值对应的填充到每个合同模板中目标签署控件的文本域中。

5.根据权利要求4所述的系统，其特征在于，所述文本控件的控件属性还包括填充类型，所述填充类型包括必填类型和非必填类型，所述处理端在将所述目标文本值填充到所述目标控件对应的文本域中时，用于：

根据每个合同模板中文本控件的填充类型，确定为必填类型的目标文本控件；

根据所述合同数据和所述目标文本控件的标识信息，确定所述合同数据中是否存在与所述目标文本控件对应的文本值；

在确定存在的情况下，将所述合同数据中对应各文本控件的文本值对应的填充到每个合同模板的文本控件的文本域中。

6.根据权利要求5所述的系统，其特征在于，在确定所述用户类型与所述多个合同模板共同对应的签署方类型不匹配和/或所述合同数据中不存在与所述目标文本控件对应的文本值的情况下，所述处理端，还用于向所述请求端返回处理失败的提示信息。

7.根据权利要求1-6任一项所述的系统，其特征在于，所述请求端，还用于向所述处理端发送合并指示信息，所述合并指示信息用于指示所述处理端对所述多个合同模板全部或部分按序合并。

8.根据权利要求7所述的系统，其特征在于，所述处理端在对填充后的多个合同模板按序合并时，用于：

根据所述合并指示信息，确定需要合并的多个目标合同模板；

按照所述请求端发送所述多个合同模板的顺序，将填充后的所述多个目标合同模板按序合并。

9.根据权利要求8所述的系统，其特征在于，所述处理端在修改页码信息时，用于：

根据所述多个目标合同模板分别包括的页码数，计算每个目标合同模板的每一页以及每一页中的控件对应的页码偏移量；

根据所述页码偏移量，对合并后多个目标合同模板的页码数以及每一页中的控件对应的页码信息进行修改。

10.一种电子合同生成方法，其特征在于，包括：

获取多个合同模板及需要填充的合同数据，所述合同数据包括每个合同模板中的控件分别对应的标识信息和文本值；

识别每个合同模板中各控件分别对应的标识信息、页码信息及坐标信息；

根据所述合同数据和每个合同模板中各控件的标识信息，确定每个合同模板中需要填充数据的目标控件，以及所述合同数据中待填充的目标文本值；

根据所述目标控件的页码信息和坐标信息，将所述目标文本值填充到所述目标控件对应的文本域中；

将填充后的所述多个合同模板按序合并以及修改对应的页码信息，以得到目标电子合同。

11.根据权利要求10所述的方法，其特征在于，所述控件包括用于签署身份信息的签署控件和用于填充指定信息的文本控件，所述签署控件的控件属性包括签署方类型，将所述目标文本值填充到所述目标控件对应的文本域中，包括：

根据每个合同模板中签署控件的签署方类型，确定所述多个合同模板共同对应的签署方类型；

根据预存的用户数据，确定预设用户中的用户类型与所述多个合同模板共同对应的签署方类型是否匹配；

在确定匹配的情况下，将所述合同数据中对应签署控件的目标文本值对应的填充到每个合同模板中目标签署控件的文本域中。

12.根据权利要求11所述的方法，其特征在于，所述文本控件的控件属性包括填充类型，所述填充类型包括必填类型和非必填类型，将所述目标文本值填充到所述目标控件对应的文本域中，包括：

根据每个合同模板中文本控件的填充类型，确定为必填类型的目标文本控件；

根据所述合同数据和所述目标文本控件的标识信息，确定所述合同数据中是否存在与所述目标文本控件对应的文本值；

在确定存在的情况下，将所述合同数据中对应各文本控件的文本值对应的填充到每个合同模板的文本控件的文本域中。

13.根据权利要求12所述的方法，其特征在于，在确定所述用户类型与所述多个合同模板共同对应的签署方类型不匹配和/或所述合同数据中不存在与所述目标文本控件对应的文本值的情况下，所述方法还包括输出处理失败的提示信息。

14.一种电子合同生成装置，其特征在于，包括：获取模块、处理模块和确定模块；

所述获取模块，用于获取多个合同模板及需要填充的合同数据，所述合同数据包括每个合同模板中的控件分别对应的标识信息和文本值；

所述处理模块，用于识别每个合同模板中各控件分别对应的标识信息、页码信息及坐标信息；

所述确定模块，用于根据所述合同数据和每个合同模板中各控件的标识信息，确定每个合同模板中需要填充数据的目标控件，以及所述合同数据中待填充的目标文本值；

所述处理模块，还用于根据所述目标控件的页码信息和坐标信息，将所述目标文本值填充到所述目标控件对应的文本域中；将填充后的所述多个合同模板按序合并以及修改对应的页码信息，以得到目标电子合同。

15.一种计算机设备，其特征在于，包括：处理器和存储器，在所述处理器执行计算机程序时，用于实现如权利要求10-13中任一项所述方法。

16.一种计算机程序产品，包括计算机程序/指令，其特征在于，当所述计算机程序/指令被处理器执行时，实现如权利要求10-13任一项所述的方法。

Images