多方项目批量申请方法及系统

技术领域

本说明书实施例涉及互联网技术领域，特别涉及一种多方项目批量申请方法。

背景技术

随着互联网技术的发展，针对审核方提供的待审核项目的项目申请，由传统的线下申请、邮寄申请和传真申请等方式，全面转向了线上申请的方式，例如，电商、仓储物流、开户/开店审核，金融、银行相关资料/资质、信用申请审核，产权、资产申请申报审核，市民政务、教育系统的跨系统资料审核等等项目申请等。

目前，在线上申请的过程中，申请方针对审核方提供的待审核项目发送项目审核请求，基于申请方的申请信息，生成对应的项目申请表并发送至审核方，以使审核方根据项目申请表，确定申请方是否有资格执行该待审核项目，得到审核结果，并将审核结果反馈给申请方，极大精简了项目申请的流程。

然而，申请方往往需要对多个跨系统的审核方发送申请，由于不同的审核方、不同的系统上有不同的审核标准和规则，对应有不同的审核等级，要求申请方提交的项目申请表也需要针对审核方不同的标准，申请方需要生成多份项目申请表，并通过各审核方对应的申请流程完成项目申请。例如，A地区的申请方通过不同系统，申请B、C、D三个地区的审核方提供的待审核项目，需要生成3份项目申请表，并通过3个不同系统对应的申请流程完成项目申请。但项目申请表中所填写的申请信息具有较高的重复性，每当申请一个新的审核方提供的待审核项目，就需要重新填写项目申请表并执行一遍上述申请流程，过程繁复，项目申请周期较长，项目申请的效率不足，项目申请的信息无法统一管理，安全性不足，用户体验不足。因此，亟需一种高效的多方项目批量申请方法。

发明内容

有鉴于此，本说明书实施例提供了一种多方项目批量申请方法。本说明书一个或者多个实施例同时涉及一种多方项目批量申请装置，一种多方项目批量申请系统，一种计算设备，一种计算机可读存储介质以及一种计算机程序，以解决现有技术中存在的技术缺陷。

根据本说明书实施例的第一方面，提供了一种多方项目批量申请方法，应用于项目申请平台，项目申请平台对应有多个审核方，包括：

接收申请方发送的项目申请请求，其中，项目申请请求针对于目标审核方提供的待审核项目，目标审核方为多个审核方中至少一个；

在申请方的第一申请信息被预先存储的情况下，获取第一申请信息；

基于第一申请信息，生成各目标审核方对应的项目申请表；

将各项目申请表发送至对应的目标审核方。

根据本说明书实施例的第二方面，提供了一种多方项目批量申请方法，应用于目标审核方，目标审核方为项目申请平台对应的多个审核方中至少一个，包括：

接收项目申请平台发送的对应的项目申请表，其中，项目申请表是基于申请方的第一申请信息生成的，第一申请信息是在第一申请信息被预先存储的情况下获取的。

根据本说明书实施例的第三方面，提供了一种多方项目批量申请装置，项目申请平台对应有多个审核方，包括：

第一接收模块，被配置为接收申请方发送的项目申请请求，其中，项目申请请求针对于目标审核方提供的待审核项目，目标审核方为多个审核方中至少一个；

获取模块，被配置为在申请方的第一申请信息被预先存储的情况下，获取第一申请信息；

第一生成模块，被配置为基于第一申请信息，生成各目标审核方对应的项目申请表；

发送模块，被配置为将各项目申请表发送至对应的目标审核方。

根据本说明书实施例的第四方面，提供了一种多方项目批量申请装置，应用于目标审核方，目标审核方为项目申请平台对应的多个审核方中至少一个，包括：

第二接收模块，被配置为接收项目申请平台发送的对应的项目申请表，其中，项目申请表是基于申请方的第一申请信息生成的，第一申请信息是在第一申请信息被预先存储的情况下获取的。

根据本说明书实施例的第五方面，提供了一种多方项目批量申请系统，系统包括申请方、项目申请平台和项目申请平台对应的至少一个目标审核方，包括：

申请方，用于发送针对目标审核方提供的待审核项目的项目申请请求；

项目申请平台，用于接收项目申请请求，在申请方的第一申请信息被预先存储的情况下，获取第一申请信息，基于第一申请信息，生成各目标审核方对应的项目申请表，将各项目申请表发送至对应的目标审核方；

目标审核方，用于接收项目申请平台发送的对应的项目申请表。

根据本说明书实施例的第六方面，提供了一种计算设备，包括：

存储器和处理器；

所述存储器用于存储计算机可执行指令，所述处理器用于执行所述计算机可执行指令，该计算机可执行指令被处理器执行时实现上述多方项目批量申请方法的步骤。

根据本说明书实施例的第七方面，提供了一种计算机可读存储介质，其存储有计算机可执行指令，该指令被处理器执行时实现上述多方项目批量申请方法的步骤。

根据本说明书实施例的第八方面，提供了一种计算机程序，其中，当所述计算机程序在计算机中执行时，令计算机执行上述多方项目批量申请方法的步骤。

本说明书一个或多个实施例中，接收申请方发送的项目申请请求，其中，项目申请请求针对于目标审核方提供的待审核项目，目标审核方为多个审核方中至少一个；在申请方的第一申请信息被预先存储的情况下，获取第一申请信息；基于第一申请信息，生成各目标审核方对应的项目申请表；将各项目申请表发送至对应的目标审核方。由于申请方的申请信息具有较高的重复性，在此基础上获取预先存储的申请信息，并对应填写至各项目申请表中，高效完成对多个审核方的提交，减少了申请方重复基于申请信息生成项目申请表，简化了各项目申请表提交审核方的繁复过程，缩短了项目申请周期，提升了项目申请的效率，提升了项目申请的信息安全性，提升了用户体验。

附图说明

图1是本说明书一个实施例提供的一种多方项目批量申请方法的流程图；

图2是本说明书一个实施例提供的另一种多方项目批量申请方法的流程图；

图3是本说明书一个实施例提供的一种多方项目批量申请方法在多电商平台开店场景下的数据流向图；

图4是本说明书一个实施例提供的一种多方项目批量申请方法的流程示意图；

图5是本说明书一个实施例提供的一种多方项目批量申请方法的前端示意图；

图6是本说明书一个实施例提供的另一种多方项目批量申请方法的前端示意图；

图7是本说明书一个实施例提供的另一种多方项目批量申请方法的前端示意图；

图8是本说明书一个实施例提供的一种多方项目批量申请方法的前端流程图；

图9是本说明书一个实施例提供的一种多方项目批量申请方法的信息流向图；

图10是本说明书一个实施例提供的另一种多方项目批量申请方法的前端流程图；

图11是本说明书一个实施例提供的另一种多方项目批量申请方法的前端流程图；

图12是本说明书一个实施例提供的另一种多方项目批量申请方法的前端流程图；

图13是本说明书一个实施例提供的另一种多方项目批量申请方法的前端流程图；

图14是本说明书一个实施例提供的另一种多方项目批量申请方法的前端流程图；

图15是本说明书一个实施例提供的一种应用于多电商平台的开店场景下的多方项目批量申请方法的处理过程流程图；

图16是本说明书一个实施例提供的一种多方项目批量申请装置的结构示意图；

图17是本说明书一个实施例提供的另一种多方项目批量申请装置的结构示意图；

图18是本说明书一个实施例提供的一种多方项目批量申请系统的结构示意图；

图19是本说明书一个实施例提供的一种计算设备的结构框图。

具体实施方式

在下面的描述中阐述了很多具体细节以便于充分理解本说明书。但是本说明书能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本说明书内涵的情况下做类似推广，因此本说明书不受下面公开的具体实施的限制。

在本说明书一个或多个实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本说明书一个或多个实施例中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本说明书一个或多个实施例中可能采用术语第一、第二等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书一个或多个实施例范围的情况下，第一也可以被称为第二，类似地，第二也可以被称为第一。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

此外，需要说明的是，本说明书一个或多个实施例所涉及的用户信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于分析的数据、存储的数据、展示的数据等)，均为经用户授权或者经过各方充分授权的信息和数据，并且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准，并提供有相应的操作入口，供用户选择授权或者拒绝。

首先，对本说明书一个或多个实施例涉及的名词术语进行解释。

批量开店：一个企业主体(申请方)在一个开店项目申请流程内完成多个电商平台的开户/开店申请与审核。

直接连接和间接连接的商户：直接连接和间接连接是从项目申请平台的视角对商户进行分类的，用于区分商户是否与项目申请平台之间建立有直接的协议关系(合约)。对于间接连接商户而言，是无法感知到项目申请平台的存在的，例如，某收单机构向项目申请平台报备了一批商户(间接连接的)，收单机构依赖于项目申请平台的收单结算能力为这批商户做收单，其中，收单机构为项目申请平台的直接连接的商户，它与项目申请平台有协议关系并直接进行项目，而被报备的商户本身与项目申请平台之间没有协议关系，属于间接连接的商户。

KYB(KnowYour Business，了解你的经营)：以企业经营相关数据为核心多维度信息。

KYC(KnowYour Customers，了解你的客户)：账户实名制信息，包括账户的实际控制人，交易的实际收益人，客户的身份、常住地址或企业所从事的项目等信息。

在本说明书中，提供了一种多方项目批量申请方法，本说明书同时涉及一种多方项目批量申请装置，一种多方项目批量申请系统，一种计算设备，一种计算机可读存储介质以及一种计算机程序，在下面的实施例中逐一进行详细说明。

参见图1，图1示出了本说明书一个实施例提供的一种多方项目批量申请方法的流程图，该方法应用于项目申请平台，项目申请平台对应有多个审核方，包括如下具体步骤：

步骤102：接收申请方发送的项目申请请求，其中，项目申请请求针对于目标审核方提供的待审核项目，目标审核方为多个审核方中至少一个。

本说明书实施例应用于提供项目申请功能的项目申请平台的应用、网页或者小程序的远程端侧，如服务端或者云侧设备。

项目申请平台为对多个审核方提供的待审核项目进行集中项目申请管理的平台，项目申请平台作为中间平台分别与申请方以及审核方建立关联关系。项目申请平台的远程端侧与申请方登录的项目申请平台的申请方客户端，以及项目申请平台的远程端侧与多个审核方的端侧之间分别建立有数据传输连接，例如，应用程序编程接口(API，ApplicationProgramming Interface)，实现申请方对待审核项目的项目申请和审核方对项目申请的审核过程中的数据传输，通过集中管理的平台实现对多个审核方的统一管理，保证了高效的项目申请和项目申请信息的高安全性。审核方为待审核项目的提供方，申请方为待审核项目的申请方。对于项目申请平台，审核方为对待审核项目的项目申请进行审核的关联方，申请方为对待审核项目提出项目申请的关联方。例如，待审核项目为开店项目，审核方为电商平台，申请方为商户或者店铺等企业主体，项目申请平台为对多个电商平台上的开店项目进行集中项目申请管理的平台。又例如，待审核项目为开户项目，审核方为银行证券等金融机构，申请方为个体或者企业，项目申请平台为对多个金融机构上的开户项目进行集中项目申请管理的平台。还例如，待审核项目为仓库项目，审核方为仓储企业，申请方为个体或者企业，项目申请平台为对多个仓储企业上的仓储申请项目进行集中项目申请管理的平台。还例如，待审核项目为物流线路项目，审核方为物流企业，申请方为商户或者店铺等企业主体，项目申请平台为对多个物流企业的物流线路项目进行集中项目申请管理的平台。

目标审核方为申请方选择进行项目申请的待审核项目的提供方，例如，待审核项目为开店项目，项目申请平台与10家电商平台建立有关联关系，这10家电商平台为审核方，开店商户从中选择3家电商平台并进行开店项目申请，这3家电商平台为目标审核方。

项目申请请求为申请方针对待审核项目进行项目申请的指令请求，项目申请请求包含但不限于：待审核项目的项目信息(例如，开店项目申请、开户项目申请、仓库项目申请、物流项目申请、信用项目申请、产权项目申请、市民政务项目申请和教育项目申请等)、目标审核方的属性信息(例如，电商平台、银行机构、证券机构、大仓库仓储企业、小仓库仓储企业、海运物流企业、空运物流企业、铁路物流企业、信用监管机构、产权交易机构、市民政务机构和学校等)申请方的标识信息(例如，账户、身份信息)和申请方的申请类型(例如，个体、企业、贸易商户、工厂商户、本科生、研究生、博士生)。具体地，项目申请平台的前端展示有多个审核方，申请方从中选择目标审核方，并对目标审核方提供的待审核项目提出项目申请，生成项目申请请求并发送至项目申请平台。

示例性地，待审核项目为开店项目，提供开店项目的审核方为电商平台，提供对开店项目进行集中项目申请管理的中间平台为A平台，申请方为B商户，A平台与20个电商平台之间构建有关联关系，B商户为A平台上的注册用户，也具有关联关系。B商户登录A平台的网页客户端，从客户端前端提供展示的20个电商平台中选择3个电商平台(电商平台1、电商平台5和电商平台6)作为目标审核方，对这3个电商平台提供的开店项目提出项目申请，生成项目申请请求并发送至A平台的云侧设备。

接收申请方发送的项目申请请求，其中，项目申请请求针对于目标审核方提供的待审核项目，目标审核方为多个审核方中至少一个，触发了项目申请流程，并为后续确定申请方的第一申请信息是否被存储提供了参考。

步骤104：在申请方的第一申请信息被预先存储的情况下，获取第一申请信息。

需要说明的是，申请方在此次项目申请流程前，可能对审核方的待审核项目进行了项目申请或者进行了申请信息存储，而项目申请平台上多个审核方之间对于申请方的申请信息要求具有高重复性，可以回调预先存储的第一申请信息，用于此次多个待审核项目的项目申请流程，避免了重新填写第一申请信息。

申请方的第一申请信息为申请方在对待审核项目进行项目申请时可重复的属性信息，包括但不限于：身份信息(例如，法人身份信息、信用号码、注册资本、登记状态、营业类型、股权状态)和交互信息(例如，电话、邮箱地址、仓库地址、退换货地址)。第一申请信息可以被预先存储在项目申请平台，进而直接从项目申请平台获取申请方的第一申请信息，也可以被预先存储在其他审核方，项目申请平台与其他审核方之间通过数据调用，获取申请方的第一申请信息。第一申请信息在项目申请平台以及不同审核方上以不同格式进行存储，例如，第一申请信息为电话，在项目申请平台上电话以11位格式和10位格式进行存储，在审核方A上电话以11位格式进行存储，在审核方B上电话以10位格式进行存储。

在申请方的第一申请信息被预先存储的情况下，获取第一申请信息，具体方式为：判断申请方的第一申请信息是否被预先存储，在申请方的第一申请信息被预先存储的情况下，获取第一申请信息。进一步地，根据申请方的标识信息，判断申请方的第一申请信息是否被预先存储，可以为根据申请方的标识信息，遍历数据库，确定申请方的第一申请信息是否被预先存储，其中，数据库可以为项目申请平台上的数据库，也可以为审核方的数据库，在此不作限定。也可以为根据申请方的标识信息，查询预设的项目申请记录表，确定申请方的第一申请信息是否被预先存储，其中，项目申请记录表是记录有申请方对各审核方提供的待审核项目的申请记录表。

另外，在申请方的第一申请信息未被预先存储的情况下，接收申请方发送的第一申请信息。第一申请信息由申请方直接提供，而无法从项目申请平台或者审核方获取得到。

示例性地，根据B商户的标识信息：账号XYZ，查询A平台上对应于B商户预设的项目申请记录表，确定B商户预先对电商平台1提供的开店项目发出过项目申请，从项目申请平台的数据库中获取B商户的第一申请信息：企业信息、法人/股东信息、店铺信息、仓库地址和退换货地址。

在申请方的第一申请信息被预先存储的情况下，获取第一申请信息，避免了申请方重新提供的高重复性的申请信息，提升了申请信息的获取效率，提升了项目申请效率，并为后续生成项目申请表奠定了信息基础。

在本说明书一种可选实施例中，步骤104包括如下具体步骤：

在申请方的第一申请信息被预先存储在项目申请平台的情况下，从项目申请平台获取第一申请信息。

申请方的第一申请信息，可以为直接预先存储在项目申请平台中的，例如，申请方在注册项目申请平台的账户时输入的注册信息，确定了待审核项目和对应的目标审核方，被存储为第一申请信息。也可以为在对预先项目申请的项目申请表中的申请信息进行存储的，例如，申请方预先对某待审核项目进行了项目申请，填写了项目申请表，提取项目申请表中填写的申请信息，存储为第一申请信息，在当前申请流程中再次对该待审核项目进行项目申请。在上述两种情况下，可以理解为申请方对于该待审核项目的申请条件和对应的目标审核方的审核规则和标准足够了解，可以直接获取第一申请信息。

在申请方的第一申请信息被预先存储在项目申请平台的情况下，从项目申请平台获取第一申请信息，具体方式为：根据申请方的标识信息，判断申请方的第一申请信息是否被预先存储在项目申请平台，在申请方的第一申请信息被预先存储在项目申请平台的情况下，从项目申请平台获取第一申请信息。进一步地，根据申请方的标识信息，判断申请方的第一申请信息是否被预先存储在项目申请平台，可以为根据申请方的标识信息，遍历项目申请平台上的数据库，确定申请方的第一申请信息是否被预先存储在项目申请平台，也可以为根据申请方的标识信息，查询预设的项目申请记录表，确定申请方的第一申请信息是否被预先存储在项目申请平台。

示例性地，B商户预先对电商平台1提供开店项目进行了项目申请，A平台的数据库中存储有B商户的第一申请信息。根据B商户的标识信息：账号XYZ，查询A平台上对应于B商户预设的项目申请记录表，确定B商户的第一申请信息被预先存储，从项目申请平台的数据库中获取B商户的第一申请信息：企业信息、法人/股东信息、店铺信息、仓库地址和退换货地址。

本说明书实施例中，在申请方的第一申请信息被预先存储在项目申请平台的情况下，从项目申请平台获取第一申请信息，进一步提升了申请信息的获取效率，进一步提升了项目申请效率，并为后续生成项目申请表奠定了信息基础。

在本说明书一种可选实施例中，步骤104包括如下具体步骤：

在申请方的第一申请信息被预先存储在关联审核方的情况下，向申请方发送信息获取请求，以使申请方确认项目申请平台是否从关联审核方获取第一申请信息；

在接收到申请方反馈的信息获取指令的情况下，从关联审核方获取第一申请信息。

需要说明的是，项目申请平台与各审核方之间的数据传输连接不仅可以实现数据接收、数据发送、数据查询等操作，还可以在此基础上实现数据共享，具体地，通过项目申请平台和审核方之间预先建立的数据调用接口，例如，应用程序编程接口(API，ApplicationProgramming Interface)，实现项目申请平台对审核方上存储数据的直接获取，进一步提升项目申请效率。

关联审核方为与申请方建立有直接关联关系的审核方，关联审核方为项目申请平台对应的多个审核方中任一个。申请方与关联审核方建立有直接关联关系，即关联审核方上存储有申请方的第一申请信息。例如，申请方预先对某待审核项目进行了项目申请，填写了项目申请表并发送给对应的审核方，该审核方审核通过，申请方与该审核方之间具有关联关系，该审核方存储有申请方的第一申请信息，该审核方为关联审核方，在当前申请流程中对另一待审核项目进行项目申请时，可以从该关联审核方直接获取第一申请信息。

信息获取请求为针对项目申请平台从关联审核方获取信息的授权请求。信息获取指令为针对项目申请平台从关联审核方获取信息的授权指令。

在申请方的第一申请信息被预先存储在关联审核方的情况下，向申请方发送信息获取请求，具体方式为：根据申请方的标识信息，判断申请方的第一申请信息是否被预先存储在关联审核方，在申请方的第一申请信息被预先存储在关联审核方的情况下，向申请方发送信息获取请求。进一步地，根据申请方的标识信息，判断申请方的第一申请信息是否被预先存储在关联审核方，可以为根据申请方的标识信息，遍历关联审核方上的数据库，确定申请方的第一申请信息是否被预先存储在关联审核方，也可以为根据申请方的标识信息，查询预设的项目申请记录表，确定申请方的第一申请信息是否被预先存储在关联审核方。

在接收到申请方反馈的信息获取指令的情况下，从关联审核方获取第一申请信息，具体方式为：在接收到申请方反馈的信息获取指令的情况下，通过项目申请平台与关联审核方之间的数据调用接口，从关联审核方获取第一申请信息。具体地，通过项目申请平台与关联审核方之间的数据调用接口，从关联审核方获取第一申请信息，包括以下方式：使用应用程序编程接口实现项目申请平台调用关联审核方的数据，例如，RESTfulAPI、SOAPAPI等。使用软件开发包(SDK，Software Development Kit)接口实现项目申请平台调用关联审核方的数据，例如，关联审核方提供了软件开发包，项目申请平台上装载有各关联审核方的软件开发包，通过运行对应的软件开发包实现数据访问。使用跨平台工具接口实现项目申请平台调用关联审核方的数据。例如，Unicode和ANSI等工具。还可以预先建立项目申请平台和关联审核方之间的共享存储空间，在其中实现数据共享，直接从该共享存储空间中调用，例如，项目申请平台和关联审核方将彼此的数据上云，通过远程云存储这一共享存储空间，实现数据调用，又例如，通过分布式存储系统完成项目申请平台对关联审核方上数据的调用。

示例性地，B商户与电商平台14之间具有直接关联关系，电商平台14为关联审核方，并且存储有B商户的第一申请信息。根据B商户：账号XYZ的标识信息，判断B商户的第一申请信息是否被预先存储在电商平台14，在B商户的第一申请信息被预先存储在电商平台14的情况下，向B商户发送信息获取请求。在接收到B商户反馈的信息获取指令的情况下，通过A平台与电商平台14之间的应用程序编程接口，从电商平台14获取第一申请信息：企业信息、法人/股东信息、店铺信息、仓库地址和退换货地址。

在申请方的第一申请信息被预先存储在关联审核方的情况下，向申请方发送信息获取请求，以使申请方确认项目申请平台是否从关联审核方获取第一申请信息，在接收到申请方反馈的信息获取指令的情况下，从关联审核方获取第一申请信息，进一步提升了申请信息的获取效率，进一步提升了项目申请效率，并为后续生成项目申请表奠定了信息基础。

在本说明书一种可选实施例中，其中，项目申请请求携带有申请方针对待审核项目的申请类型；

对应地，在申请方的第一申请信息被预先存储在关联审核方的情况下，向申请方发送信息获取请求，包括如下具体步骤：

在申请方的第一申请信息被预先存储在关联审核方的情况下，根据申请类型和待审核项目的项目属性，确定申请方是否满足待审核项目的申请条件；

若是，向申请方发送信息获取请求。

目前，对于不同的审核方具有不同的审核标准，审核方对应的监管部门具有不同的项目申请要求和风控等级，因而，在正式生成项目申请表之前，需要对申请方进行资质预审核，避免无效申请和审核，提升项目申请的申请效率。

申请类型为申请方针对于待审核项目的主体类型，包括申请性质和申请方类型，申请性质为申请方针对于待审核项目的主体性质类型，包括组织申请(例如，企业申请、商户申请、店铺申请)或者个人申请，申请方类型为申请方针对于待审核项目的主体项目角色类型，包括独立完成项目(例如，贸易商户(无自营工厂))和非独立完成项目(例如，工厂商户(自营工厂))。具体地，申请方在项目申请平台的前端，输入申请方针对待审核项目的申请类型，项目申请平台的客户端基于此生成项目申请请求，项目申请请求携带有申请类型。待审核项目的项目属性为待审核项目的项目资质属性，表征了审核方的申请条件与资质要求，例如，待审核项目为开店项目，待审核项目的项目属性为面向于注册资本在XXX元以上的企业。

待审核项目的申请条件为待审核项目针对于审核方的可行性判断条件。包括可申请和不可申请。在确定申请方满足待审核项目的申请条件的情况下，根据申请方的项目申请表进行进一步的审核，避免了无效审核，降低了申请成本和审核成本，提升了项目申请的效率。

在申请方的第一申请信息被预先存储在关联审核方的情况下，根据申请类型和待审核项目的项目属性，确定申请方是否满足待审核项目的申请条件，具体方式为：根据申请方的标识信息，判断申请方的第一申请信息是否被预先存储在关联审核方，在申请方的第一申请信息被预先存储在关联审核方的情况下，根据申请类型和待审核项目的项目属性，确定申请方是否满足待审核项目的申请条件。进一步地，根据申请方的标识信息，判断申请方的第一申请信息是否被预先存储在关联审核方，可以为根据申请方的标识信息，遍历关联审核方上的数据库，确定申请方的第一申请信息是否被预先存储在关联审核方，也可以为根据申请方的标识信息，查询预设的项目申请记录表，确定申请方的第一申请信息是否被预先存储在关联审核方。

示例性地，B商户预先对电商平台1提供开店项目进行了项目申请，A平台的数据库中存储有B商户的第一申请信息。根据B商户的标识信息：账号XYZ，查询A平台上对应于B商户预设的项目申请记录表，确定B商户的第一申请信息被预先存储，根据B商户的申请类型(申请性质：企业社情；申请方类型：工厂商户)和电商平台1的开店项目的项目属性(自营企业)，确定B商户满足电商平台1的开店项目的申请条件，向B商户方发送信息获取请求。

在申请方的第一申请信息被预先存储在关联审核方的情况下，根据申请类型和待审核项目的项目属性，确定申请方是否满足待审核项目的申请条件，若是，向申请方发送信息获取请求，避免了无效审核，降低了申请成本和审核成本，进一步提升了项目申请效率，并为后续生成项目申请表奠定了信息基础。

在本说明书一种可选实施例中，在申请方的第一申请信息被预先存储在关联审核方的情况下，向申请方发送信息获取请求之后，还包括如下具体步骤：

在未接收到申请方反馈的信息获取指令的情况下，将各目标审核方对应的初始项目申请表发送至申请方；

接收申请方发送的第一申请信息。

出于信息安全、信息更新等方面的考量，申请方在接收到信息获取请求后，不对项目申请平台从关联审核方获取信息进行授权，即不发送信息获取指令，在这种情况下，为了生成项目申请表，需要从申请方处接收第一申请信息。

初始项目申请表为审核方提供的不包含第一申请信息的信息表单，初始项目申请表包含多个信息标签和信息域，信息标签对应于各审核方的审核标准和规则，信息域中未添加对应的申请信息。初始项目申请表可以为空白表单，也可以为包含待审核项目的项目属性的预填表单，在此不作限定。例如，初始项目申请表包含15个信息标签：法人身份信息、营业类型、股权状态、电话、邮箱地址、仓库地址、退换货地址……，在15个信息标签对应的信息域中未添加有对应的申请信息，如表1所示：

表1

申请方发送的第一申请信息，可以为申请方输入的第一申请信息，也可以为申请方通过本地数据库获取的第一申请信息，在此不作限定。申请方发送的第一申请信息与初始项目申请表是对应的，具体对应于初始项目申请表中多个信息标签。

示例性地，在未接收到B商户反馈的信息获取指令的情况下，将各电商平台(电商平台1、电商平台5和电商平台6)对应的空白项目申请表发送至申请方，接收申请方发送的第一申请信息：企业信息、法人/股东信息、店铺信息、仓库地址和退换货地址。

在未接收到申请方反馈的信息获取指令的情况下，将各目标审核方对应的初始项目申请表发送至申请方，接收申请方发送的第一申请信息，提升了项目申请的通用度，适应于申请方的不同的申请要求。

在本说明书一种可选实施例中，该方法还包括如下具体步骤：

接收各初始项目申请表对应的第二申请信息；

基于第一申请信息和各初始项目申请表对应的第二申请信息，生成各目标审核方对应的项目申请表。

申请方的第二申请信息为申请方在对待审核项目进行项目申请时不可重复的属性信息，例如，审核方提供的邀请码，申请方和审核方之间的专属优惠信息，针对于审核方的汇款路径等，第二申请信息需要申请方自行补充，可以理解为一种不可重复的补充信息。

基于第一申请信息和各初始项目申请表对应的第二申请信息，生成各目标审核方对应的项目申请表，具体方式为：在各初始项目申请表中添加第一申请信息和对应的第二申请信息，得到各目标审核方对应的项目申请表。进一步地，在各初始项目申请表信息标签对应的信息域中添加第一申请信息和对应的第二申请信息，得到各目标审核方对应的项目申请表。

具体地，在前端展示各初始项目申请表，在各初始项目申请表中添加第一申请信息和各初始项目申请表对应的第二申请信息，得到项目申请表后对前端展示的各初始项目申请表进行替换。

示例性地，在3个初始项目申请表InitialForm1、InitialForm2和InitialForm3中，信息标签“企业信息”、“法人/股东信息”、“店铺信息”、“仓库地址”、“退换货地址”和“汇款路径”对应的信息域中添加第一申请信息和第二申请信息，得到3个电商平台(电商平台1、电商平台5和电商平台6)对应的项目申请表：Form1、Form2和Form3，在A平台的网页客户端的前端上展示3个项目申请表。

接收各初始项目申请表对应的第二申请信息，基于第一申请信息和各初始项目申请表对应的第二申请信息，生成各目标审核方对应的项目申请表，提升了项目申请的通用度，适应于申请方的不同的申请要求。

步骤106：基于第一申请信息，生成各目标审核方对应的项目申请表。

项目申请表为对待审核项目进行项目申请提供的申请方信息表单。由于各审核方有不同的审核标准和规则，项目申请表与目标审核方对应。例如，电商平台1采用a货币进行结算，电商平台2采用b货币进行结算，因而，电商平台1对应的项目申请表中要求提供a货币对应的结算账户，电商平台2对应的项目申请表中要求提供b货币对应的结算账户。项目申请表包含多个信息标签和信息域，信息标签对应于各审核方的审核标准和规则，信息域中添加对应的申请信息。

例如，项目申请表包含15个信息标签：法人身份信息、营业类型、股权状态、电话、邮箱地址、仓库地址、退换货地址……，在15个信息标签对应的信息域中添加有对应的申请信息：法人A、电子产品、14个股东、1****0、***.com、XX路XX号XX室、YY路YY号……，如表2所示：

表2

基于第一申请信息，生成各目标审核方对应的项目申请表，具体方式为：根据各目标审核方对应的项目申请表中的信息标签，确定对应的第一申请信息，根据信息标签对应的信息域，对第一申请信息进行归一化处理，并添加至对应的信息域中，得到各目标审核方对应的项目申请表。根据各目标审核方对应的项目申请表中的信息标签，确定对应的第一申请信息，可以为利用预先训练的标签相似算法确定，例如，利用神经网络模型进行向量编码，比较两者间的向量相似度，还可以为利用预先构建的知识图谱或者键值对等确定对应的信息标签，还可以为利用预设的标签数据关系表确定，在此不作限定。归一化处理通过预先设置的归一化算法来实现，例如，格式转换，对数指数转换，区间映射正则归一化。

可选地，基于第一申请信息，生成各目标审核方对应的项目申请表，并将各项目申请表展示在前端。在此基础上，申请方可以对前端展示的项目申请表进行编辑，得到最终的项目申请表。具体的编辑方法，可以为直接生成包含第一申请信息的项目申请表，申请方再对其他中的信息进行编辑(增加、删除或者更改)，也可以为得到申请信息备份数据并展示在前端，申请方对其进行点选后生成项目申请表，在此不作限定。

示例性地，B商户的第一申请信息：企业信息、法人/股东信息、店铺信息、仓库地址和退换货地址……，根据3个电商平台(电商平台1、电商平台5和电商平台6)对应的项目申请表中的信息标签：电商平台1：(企业，法人，股东，店铺信息，仓储)；电商平台2：(公司信息，法人信息，股东信息，店铺信息，仓库信息，退换货方式)；电商平台3：(企业信息，法人/股东信息，商铺信息，仓储信息，退换货信息)，利用神经网络模型进行向量编码，计算向量相似度，根据向量相似度，确定对应的第一申请信息，根据信息标签对应的信息域，利用归一化算法，对第一申请信息进行归一化处理后，填入信息域中，得到3个电商平台对应的项目申请表：Form1、Form2和Form3，并在A平台的网页客户端的前端上展示3个项目申请表：Form1、Form2和Form3。

基于第一申请信息，生成各目标审核方对应的项目申请表，避免了申请方基于高重复性的申请信息，重复生成多份项目申请表，提升了项目申请表的生成效率，提升了项目申请效率，并为后续发送项目申请表奠定了表单基础。

在本说明书一种可选实施例中，步骤106包括如下具体步骤：

在各初始项目申请表中添加第一申请信息，得到各目标审核方对应的项目申请表。

初始项目申请表为未添加第一申请信息的项目申请表。各审核方的初始项目申请表包含不同组合的信息标签，不同初始项目申请表中信息标签对应不同格式的申请信息。例如，电商平台1对应的初始项目申请表包含10个信息标签：法人身份信息、营业类型、电话、邮箱地址、仓库地址、退换货地址……，其中，法人身份信息要求填写中文格式姓名以及18位编号格式身份号码，电话要求填写11位编号格式的电话号码，仓库地址要求从大地址到小地址填写，退换货地址要求从大地址到小地址填写。填写电商平台2对应的初始项目申请表包含9个信息标签：法人信息、营业范围、联系方式、是否有本地仓库、是否支持异地退换货……，其中，法人信息要求填写英文格式姓名以及9—11位编号格式身份号码，联系方式要求填写10位编号格式的电话号码或者邮箱地址，是否有本地仓库要求填写是或者否，并在是的情况下从小地址到大地址填写仓库地址，退换货地址要求填写是或者否，并在是的情况下从小地址到大地址填写退换货地址。生成各审核方对应的项目申请表时，按照项目审核方的信息标签确定对应的申请信息，按照项目审核方的信息域进行信息格式的转换，进行信息添加，得到对应的项目申请表。

在本说明书一种可选实施例中，在各初始项目申请表中添加第一申请信息，得到各目标审核方对应的项目申请表，包括如下具体步骤：

根据各初始项目申请表的信息标签，确定对应的第一申请信息；

对第一申请信息进行对应的格式转换，在信息标签对应的信息域中条件转换后的第一申请信息，得到各目标审核方对应的项目申请表。

确定对应的第一申请信息的方式，已在上述实施例中详细说明，在此不再赘述。格式转换的方式包括，字符串转整数算法、数位填充或者删除算法等。可参见上述表1和表2的内容。具体地，在前端展示各初始项目申请表，在各初始项目申请表中添加第一申请信息，即为利用预先获取的信息对初始项目信息表进行回填，在得到项目申请表后对前端展示的各初始项目申请表进行替换。

示例性地，根据3个电商平台对应的3个初始项目申请表InitialForm1、InitialForm2和InitialForm3中的信息标签：初始项目申请表InitialForm1：(企业，法人，股东，店铺信息，仓储)；初始项目申请表InitialForm2：(公司信息，法人信息，股东信息，店铺信息，仓库信息，退换货方式)；初始项目申请表InitialForm3：(企业信息，法人/股东信息，商铺信息，仓储信息，退换货信息)，利用神经网络模型进行向量编码，计算向量相似度，根据向量相似度，确定对应的第一申请信息，根据信息标签对应的信息域，利用字符串转整数算法、数位填充或者删除算法等预先设置的格式转换算法，对第一申请信息进行格式转换后，在信息标签“企业信息”、“法人/股东信息”、“店铺信息”、“仓库地址”和“退换货地址”对应的信息域中添加第一申请信息，得到3个电商平台(电商平台1、电商平台5和电商平台6)对应的项目申请表：Form1、Form2和Form3，并在A平台的网页客户端的前端上展示3个项目申请表：Form1、Form2和Form3。

在各初始项目申请表中添加第一申请信息，得到各目标审核方对应的项目申请表，通过自动添加第一申请信息的方式，避免了申请方在重复多份初始项目申请表中添加第一申请信息，提升了项目申请表的生成效率，提升了项目申请效率，并为后续发送项目申请表奠定了表单基础。

在本说明书一种可选实施例中，在各初始项目申请表中添加第一申请信息，得到各目标审核方对应的项目申请表，包括如下具体步骤：

在各初始项目申请表中添加第一申请信息，得到各目标审核方对应的第一项目申请表；

将各第一项目申请表发送至申请方；

接收申请方发送的各第一项目申请表对应的第二申请信息；

在各第一项目申请表中添加对应的第二申请信息，得到各目标审核方对应的项目申请表。

申请方的第二申请信息为申请方在对待审核项目进行项目申请时不可重复的属性信息，例如，审核方提供的邀请码，申请方和审核方之间的专属优惠信息，针对于审核方的汇款路径等，第二申请信息需要申请方自行补充，可以理解为一种不可重复的补充信息。

第一项目申请表为对待审核项目进行项目申请提供第一申请信息的信息表单，第一项目申请表包含多个信息标签和信息域，信息标签对应于各审核方的审核标准和规则，信息域中添加对应的第一申请信息。具体是通过信息标签确定对应的第一申请信息，并进行了格式转换后在信息域中添加对应的第一申请信息，参见上述实施例的详细说明。例如，初始项目申请表包含15个信息标签：法人身份信息、营业类型、股权状态、电话、邮箱地址、仓库地址、退换货地址、邀请码和专属优惠信息，在15个信息标签对应的信息域中添加了第一申请信息后，得到第一项目申请表如表3所示：

表3

第一项目申请表是在初始项目申请表中添加了第一申请信息的信息表单，项目申请表是在第一项目申请表中添加了第二申请信息的信息表单。在表3中添加了第二申请信息：YHCH(邀请码)、专属优惠信息(7.5折)，得到项目申请表如表4所示：

表4

在各初始项目申请表中添加第一申请信息，得到各目标审核方对应的第一项目申请表，具体方式为：在各初始项目申请表信息标签对应的信息域中添加第一申请信息，得到各目标审核方对应的项目申请表。

将各第一项目申请表发送至申请方，具体方式为：将各第一项目申请表发送至申请方并在前端展示。

在各第一项目申请表中添加对应的第二申请信息，得到各目标审核方对应的项目申请表，具体方式为：在各第一项目申请表信息标签对应的信息域中添加第二申请信息，得到各目标审核方对应的项目申请表。

具体地，在前端展示各初始项目申请表，在各初始项目申请表中添加第一申请信息，即为利用预先获取的信息对初始项目信息表进行回填，在得到第一项目申请表后对前端展示的各初始项目申请表进行替换，申请方根据第一项目申请表输入第二申请信息，在第一项目申请表中添加第二申请信息，得到项目申请表后对前端展示的各第一项目申请表进行替换。

示例性地，在3个初始项目申请表InitialForm1、InitialForm2和InitialForm3中，信息标签“企业信息”、“法人/股东信息”、“店铺信息”、“仓库地址”和“退换货地址”对应的信息域中添加第一申请信息，得到3个电商平台(电商平台1、电商平台5和电商平台6)对应的第一项目申请表：RefForm1、RefForm2和RefForm3，并将3个第一项目申请表发送至B商户，在A平台的网页客户端的前端上展示3个第一项目申请表：RefForm1、RefForm2和RefForm3，接收B商户发送的第一项目申请表对应的第二申请信息：针对于3个电商平台的汇款路径，在第一项目申请表中，信息标签“汇款路径”对应的信息域中添加第二申请信息，得到3个电商平台(电商平台1、电商平台5和电商平台6)对应的项目申请表：Form1、Form2和Form3，在A平台的网页客户端的前端上展示3个项目申请表。

在各初始项目申请表中添加第一申请信息，得到各目标审核方对应的第一项目申请表，将各第一项目申请表发送至申请方，接收申请方发送的各第一项目申请表对应的第二申请信息，在各第一项目申请表中添加对应的第二申请信息，得到各目标审核方对应的项目申请表。进一步丰富了项目申请的通用度，提升了项目申请效率的同时，提升了项目申请的准确度。

步骤108：将各项目申请表发送至对应的目标审核方。

将各项目申请表发送至对应的目标审核方，可以为在接收到申请方发送的发送指令的情况下，将各项目申请表发送至对应的目标审核方，也可以为直接将各项目申请表发送至对应的目标审核方。

示例性地，将项目申请表Form1发送至电商平台1的端侧，将项目申请表Form2发送至电商平台5的端侧，将项目申请表Form3发送至电商平台6的端侧。

本说明书实施例中，接收申请方发送的项目申请请求，其中，项目申请请求针对于目标审核方提供的待审核项目，目标审核方为多个审核方中至少一个；在申请方的第一申请信息被预先存储的情况下，获取第一申请信息；基于第一申请信息，生成各目标审核方对应的项目申请表；将各项目申请表发送至对应的目标审核方。由于申请方的申请信息具有较高的重复性，在此基础上获取预先存储的申请信息，并对应填写至各项目申请表中，高效完成对多个审核方的提交，减少了申请方重复基于申请信息生成项目申请表，简化了各项目申请表提交审核方的繁复过程，缩短了项目申请周期，提升了项目申请的效率，提升了项目申请的信息安全性，提升了用户体验。

在本说明书一种可选实施例中，在步骤108之后，还包括如下具体步骤：

接收各目标审核方发送的审核结果，并将各审核结果发送至申请方。

需要说明的是，在步骤108中，向目标审核方发送项目申请表，即完成了一次项目申请的申请流程，进而进入项目申请的审核流程，审核方对申请方的项目申请表进行审核，得到审核结果。

审核结果为目标审核方针对项目申请确定的申请审核结果，包括但不限于：通过、不通过和审核中，其中，审核中包括审核进度和/或补充申请信息。审核结果是根据项目申请表确定的。进一步地，审核结果是根据项目申请表和申请方的行为数据确定的，申请方的行为数据可以通过关联审核方或者项目申请平台获取得到。

示例性地，接收电商平台1的端侧发送的审核结果：通过，接收电商平台5的端侧发送的审核结果：审核中、60％，接收电商平台6的端侧发送的审核结果：不通过。

接收各目标审核方发送的审核结果，并将各审核结果发送至申请方，高效完成多个审核方的审核，减少了申请方多次发送项目申请表，并接收审核结果，缩短了项目申请周期，提升了项目申请的效率，提升了用户体验。

参见图2，图2示出了本说明书一个实施例提供的另一种多方项目批量申请方法的流程图，该方法应用于目标审核方，目标审核方为项目申请平台对应的多个审核方中至少一个，包括如下具体步骤：

步骤202：接收项目申请平台发送的对应的项目申请表，其中，项目申请表是基于申请方的第一申请信息生成的，第一申请信息是在第一申请信息被预先存储的情况下获取的。

本说明书实施例应用于具有项目申请审核功能的目标审核方的端侧。

步骤202中的内容已在上述图1实施例中详细说明，在此不再赘述。

本说明书实施例中，接收项目申请平台发送的对应的项目申请表，其中，项目申请表是基于申请方的第一申请信息生成的，第一申请信息是在第一申请信息被预先存储的情况下获取的。由于申请方的申请信息具有较高的重复性，在此基础上获取预先存储的申请信息，并对应填写至各项目申请表中，高效完成对多个审核方的提交，减少了申请方重复基于申请信息生成项目申请表，简化了各项目申请表提交审核方的繁复过程，缩短了项目申请周期，提升了项目申请的效率，提升了项目审核的信息安全性，提升了用户体验。

在本说明书一种可选实施例中，在步骤202之后，还包括如下具体步骤：

根据项目申请表，确定审核结果，将审核结果发送至项目申请平台。

根据项目申请表，确定审核结果，将审核结果发送至项目申请平台，具体方式为：根据项目申请表的第一申请信息和/或第二申请信息，确定审核结果，将审核结果发送至项目申请平台。

在将审核结果发送至项目申请平台之后，申请方可以在项目申请平台上确定审核结果，申请方也可以接收项目申请平台转发的审核结果，在此不作限定。

示例性地，目标审核方为电商平台1，根据项目申请表Form1的第一申请信息和第二申请信息，确定审核结果：通过，将审核结果(通过)发送至A平台，以使A平台将审核结果(通过)转发至B商户。

根据项目申请表，确定审核结果，将审核结果发送至项目申请平台，提升了项目审核的准确度。

在本说明书一种可选实施例中，根据项目申请表，确定审核结果，包括如下具体步骤：

从项目申请平台获取来自关联审核方的申请方的行为数据；

根据项目申请表和行为数据，确定审核结果。

申请方的行为数据为申请方与关联审核方之间的交互性行为数据，例如，关联审核方为电商平台，申请方为某地区商户，某地区商户与电商平台之间存在商品物流、汇款行为等行为数据，结合该行为数据和目标审核方对应的项目申请表，可以更为准确地确定审核结果，是一种双向核验方法。

从项目申请平台获取来自关联审核方的申请方的行为数据，根据项目申请表和行为数据，确定审核结果，进一步提升了项目审核的准确度。

图3示出了本说明书一个实施例提供的一种多方项目批量申请方法在多电商平台开店场景下的数据流向图，如图3所示：

A商户在多个电商平台开店，需要提供企业信息、法人/股东信息、店铺信息、仓库地址和退换货地址的申请信息，通过项目申请平台的自动核验API，结合多个电商平台的申请条件与资质要求，以及KYB/KYC进行批量开店/开户，实现电商、贸易、物流仓储和其他项目的申请，其中，KYB/KYC来自电商平台数据。

图4示出了本说明书一个实施例提供的一种多方项目批量申请方法的流程示意图，如图4所示：

申请方选择申请方的申请类型(企业/个人)，选择申请的审核方(单选/多选)，即确定待审核项目，根据申请类型，显示待审核项目的项目属性，确定第一申请信息存储在项目申请平台或者关联审核方。在第一申请信息存储在项目申请平台的情况下，从项目申请平台获取第一申请信息，基于第一申请信息生成第一项目申请表。在第一申请信息存储在关联审核方的情况下，在前端展示初始项目申请表，获得申请方的申请类型，基于申请类型和项目属性，确定申请方是否满足待审核项目的申请条件，若是，申请方确定是否授权项目申请平台从关联审核方获取第一申请信息，若是，从关联审核方获取第一申请信息，基于第一申请信息，生成第一项目申请表，若否，人工添加第一申请信息和第二申请信息至初始项目申请表，得到项目申请表，发送审核方审核。在第一项目申请表中添加申请方发送的第二申请信息，得到项目申请表，同时发送多个项目申请表至对应的审核方，审核方审核。审核方反馈审核结果/申请方在项目申请平台上查看审核进度，返回结束。

图5示出了本说明书一个实施例提供的一种多方项目批量申请方法的前端示意图，如图5所示：

在开店项目申请平台的前端界面，开店项目申请的执行流程为：选择开店类型和电商平台、填写开店项目申请表、开店项目审核和开店成功，当前前端界面为填写开店项目申请表。在当前前端界面中，选择开店类型和电商平台，对应标签，申请方通过下拉“请选择/新增开店类型”进行选择，并且显示有填写提醒“在您选择/新增本次申请的开店类型后，我们将根据您的申请信息为您展示和预填项目申请表，您也可以对项目申请表进行修改”，申请方根据填写提醒选择对应的开店类型后，在下方选择申请电商平台(多选)，其中，电商平台包括：电商平台1、电商平台2、电商平台3、电商平台4、电商平台5、电商平台6……，可以点选“展开更多”在前端界面显示所有电商平台，在完成选择后，可以点选“下一步”，也可以对当前填写开店项目申请表进行保存，用于后续自动回填开店项目申请表。

图6示出了本说明书一个实施例提供的另一种多方项目批量申请方法的前端示意图，如图6所示：

在开店项目申请平台的前端界面，填写开店项目申请表的执行流程为：申请类型信息、运营信息、联系方式和确认结果。在申请类型信息的填写界面中，填写商户的申请类型信息，包括选择申请性质：企业申请或者个人申请(当前选择为企业申请)，还包括选择申请方类型：贸易商户(无自营工厂)或者工厂商户(自营工厂)，完成点选后，申请方通过下拉“请选择/新增开店类型”进行选择，可以通过点选两个“选择可回填的电商平台信息”，弹出“申请电商平台(多选)”的弹窗，选择对应的电商平台(电商平台1、电商平台2、电商平台3、电商平台4、电商平台5、电商平台6……)，完成申请类型信息填写后，可以点选“下一步”，也可以对当前填写开店项目申请表进行保存，用于后续自动回填开店项目申请表。

图7示出了本说明书一个实施例提供的另一种多方项目批量申请方法的前端示意图，如图7所示：

在开店项目申请平台的前端界面，开店项目申请的执行流程为：选择开店类型和电商平台、填写开店项目申请表、开店项目审核和开店成功，当前前端界面为填写开店项目申请表。在当前前端界面中，选择开店类型和电商平台，对应标签，申请方通过下拉“请选择/新增开店类型”进行选择，并且在下方显示有填写提醒“在您选择/新增本次申请的开店类型后，我们将根据您的申请信息为您展示和预填项目申请表，您也可以对项目申请表进行修改”，申请方根据填写提醒选择对应的开店类型后，在下方选择申请电商平台(多选)，其中，电商平台包括：电商平台1、电商平台2、电商平台3、电商平台4、电商平台5、电商平台6……，可以点选“展开更多”在前端界面显示所有电商平台，申请方点选电商平台1、电商平台5和电商平台6，在界面的右侧显示电商平台的申请条件与资质要求和提示信息“请仔细查看各电商平台的申请条件与资质要求，核实您的申请信息后再提交，若您提交的申请信息不符合申请条件与资质要求，可能不会通过电商平台的审核，感谢您的配合”，用户通过查看这3个电商平台的申请条件与资质要求，进行电商平台的选择后，可以点选“下一步”，也可以对当前填写开店项目申请表进行保存，用于后续自动回填开店项目申请表。

图8示出了本说明书一个实施例提供的一种多方项目批量申请方法的前端流程图，如图8所示：

申请方选择批量开店到前端显示初始项目申请表的前端流程如下：1、申请方发送选择批量开店至后台门户；2、后台门户发送选择批量开店至可视化页面渲染；3、可视化页面渲染发送选择批量开店至后端模型1；4、后台模型1发送选择批量开店至后端模型2；5、后端模型2从参数中心选择电商平台对应的初始项目申请表；6、参数中心返回电商平台的申请条件与资质要求至后端模型2；7、后端模型2返回初始项目申请表至后端模型1；8、后端模型1返回初始项目申请表至可视化页面渲染；9、可视化页面渲染在后台门户上渲染初始项目申请表。

图9示出了本说明书一个实施例提供的一种多方项目批量申请方法的信息流向图，如图9所示：

与开店项目申请平台存在数据传输连接有直接连接商户、收单机构(例如，银行)和平台型商户。可以从直接连接商户，完成对直接连接商户的店铺的信息获取。可以通过收单机构，通过间接连接模式：从间接连接商户，完成对间接连接商户的店铺的信息获取。可以从平台型商户，完成对平台自身商户的信息获取。

图10示出了本说明书一个实施例提供的另一种多方项目批量申请方法的前端流程图，如图10所示：

商户查询详细信息的前端流程如下：商户通过Imhome实现：1、信息查询。Imhome从Imif上实现：1.1、查询商户详细信息。Imif向Imhome：1.2、返回商户详细信息。Imhome向商户：1.3、返回商户详细信息。

图11示出了本说明书一个实施例提供的另一种多方项目批量申请方法的前端流程图，如图11所示：

门户或者IBOSS等，从商户核心上，查询商户完整信息，或者查询间接连接商户完整信息。

图12示出了本说明书一个实施例提供的另一种多方项目批量申请方法的前端流程图，如图12所示：

申请方提交开店申请到生成项目申请表的前端流程如下：1、申请方提交开店申请至后台门户；2、后台门户提交开店申请至可视化页面渲染；3、可视化页面渲染向后端模型1查询申请方的第一申请信息；4、后台模型1向后端模型2查询申请方的第一申请信息；5、后端模型2在后端模型3上，通过数据调用接口，从关联电商平台获取申请方的第一申请信息；6、后端模型3向后端模型2，返回申请方的第一申请信息，如果语言偏好是中文，返回拼音；7、后端模型2返回申请方的第一申请信息至后端模型1；8、后端模型1返回申请方的第一申请信息至可视化页面渲染；9、可视化页面渲染返回申请方的第一申请信息至后台门户；10、后台门户在初始项目申请表中添加第一申请信息，得到项目申请表。

图13示出了本说明书一个实施例提供的另一种多方项目批量申请方法的前端流程图，如图13所示：

申请方保存项目申请表到确定是否有接口请求异常记录的前端流程如下：1、申请方向后台门户申请保存项目申请表；2、后台门户向可视化页面渲染申请保存项目申请表；3、可视化页面渲染向后端模型1申请保存项目申请表；4、后端模型1向后端模型2申请保存项目申请表，设置密码为XXX；5、后端模型2查看当前密码和账号是否有接口请求异常记录；6、后端模型2返回结果至后端模型1；7、后端模型1返回结果至可视化页面渲染；8、可视化页面渲染返回结果至后台门户；9、后台门户返回结果至申请方。

图14示出了本说明书一个实施例提供的另一种多方项目批量申请方法的前端流程图，如图14所示：

申请方从点解开店查询是否有项目申请表至返回查询结果的前端流程如下：1、申请方点击开店查询是否有项目申请表至后台门户；2、后台门户发送点击开店查询是否有项目申请表至后台门户至可视化页面渲染；3、可视化页面渲染发送点击开店查询是否有项目申请表至后台门户至后端模型1；4、后端模型1在后端模型2上查询项目申请表，设置密码为XXX；5、后端模型2通过账号和密码查询所有接口调用请求，如果没有接口调用请求异常，确定状态为“成功”，不用设置项目申请表内容，如果有接口调用请求异常，设置状态为“异常”，设置项目申请表为异常；6、后端模型2返回结果至后端模型1；7、后端模型1返回结果至可视化页面渲染；8、可视化页面渲染返回结果至后台门户；9、后台门户返回结果至申请方。

下述结合附图15，以本说明书提供的多方项目批量申请方法在多电商平台开店场景的应用为例，对所述多方项目批量申请方法进行进一步说明。其中，图15示出了本说明书一个实施例提供的一种应用于多电商平台的开店场景下的多方项目批量申请方法的处理过程流程图，该方法应用于开店项目申请平台，该开店项目申请平台对应有多个电商平台，包括如下具体步骤：

步骤1502：接收A商户发送的开店项目申请请求。

目前，随着商家经营能力与范围的扩展，多平台开户/开店(贸易/电商/物流等)，多系统集成(例如，网页、应用、超文本标记语言产品(H5)和小程序)，涉及到线上线下多场景，从传统店铺经营到电商平台，小程序，短视频，再到仓储物流、供应链、独立站等。在与不同地区，不同渠道/平台，多系统间开展项目合作，都需要提供大量的申请信息(企业信息、经营数据、银行账户、法人信息、信用状态等进行入驻、开店、提供服务、获得服务)进行资质审核和监管。不同申报/申请的项目，对应的平台、部门、机构都包含不同的项目资质要求和监管等级。其中，申请方提交的项目申请表包括KYB、KYC、董事、股东信息。经营品牌、品类、店铺信息、区域范围、店铺地址、退换货地址、收付款/提款转账银行账户、第三方账户、缴税信息、经营年流水、总体库存数等第一申请信息和第二申请信息，不同电商平台的审核流程、审核标准和审核周期也各不相同，商户每申请一个电商平台，就要重新项目申请流程，重新填写一遍项目申请表，因而过程繁复，开店项目周期较长，开店项目申请效率低，风险高，用户体验不足。

步骤1504：在A商户的第一申请信息被预先存储在开店项目申请平台的情况下，从开店项目申请平台获取第一申请信息。

步骤1506：在A商户的第一申请信息被预先存储在关联电商平台的情况下，根据申请类型和开店项目的项目属性，确定A商户是否满足开店项目的申请条件，若是，向A商户发送信息获取请求。

步骤1508：在接收到A商户反馈的信息获取指令的情况下，通过关联电商平台设置在开店项目申请平台上的应用程序编程接口，从关联电商平台获取第一申请信息。

步骤1510：根据神经网络模型，计算第一申请信息和初始项目申请表中信息标签的相似度，确定对应的第一申请信息，利用归一化算法完成对第一申请信息的归一化处理，在对应的信息域中添加第一申请信息，得到各目标电商平台对应的第一项目申请表，将各第一项目申请表发送至A商户，接收A商户发送的各第一项目申请表对应的第二申请信息，在各第一项目申请表中添加对应的第二申请信息，得到各目标电商平台对应的项目申请表。

步骤1512：在未接收到A商户反馈的信息获取指令的情况下，将各目标电商平台对应的初始项目申请表发送至A商户，接收A商户发送的第一申请信息和各初始项目申请表对应的第二申请信息，将第二申请信息填入第一项目申请表中对应的信息域，得到各目标电商平台对应的项目申请表。

步骤1514：将各项目申请表发送至对应的目标电商平台。

步骤1516：接收各目标电商平台发送的审核结果，并将各审核结果发送至A商户。

本说明书实施例中，通过开店项目申请平台，实现了商户和电商平台的双向核验，提供了更为安全和高效的开店项目申请方案。集中管理了对电商平台和监管部门在资质要求、审核流程、周期时限、技术接口、数据安全和风控等级的基础要求与特殊要求，高效且安全地获取商户的第一申请信息和第二申请信息，生成项目申请表并发送至对应的电商平台，以减少商户重复填写申请信息并提交项目申请，同时提高了申请信息填写效率与准确性，降低了项目申请成本和审核成本，提升了开店项目申请的效率和安全性。

与上述方法实施例相对应，本说明书还提供了多方项目批量申请装置实施例，图16示出了本说明书一个实施例提供的一种多方项目批量申请装置的结构示意图。如图16所示，该装置应用于项目申请平台，项目申请平台对应有多个审核方，该装置包括：

第一接收模块1602，被配置为接收申请方发送的项目申请请求，其中，项目申请请求针对于目标审核方提供的待审核项目，目标审核方为多个审核方中至少一个；

获取模块1604，被配置为在申请方的第一申请信息被预先存储的情况下，获取第一申请信息；

第一生成模块1606，被配置为基于第一申请信息，生成各目标审核方对应的项目申请表；

发送模块1608，被配置为将各项目申请表发送至对应的目标审核方。

可选地，获取模块1604被进一步配置为：在申请方的第一申请信息被预先存储在项目申请平台的情况下，从项目申请平台获取第一申请信息。

可选地，获取模块1604被进一步配置为：在申请方的第一申请信息被预先存储在关联审核方的情况下，向申请方发送信息获取请求，以使申请方确认项目申请平台是否从关联审核方获取第一申请信息；在接收到申请方反馈的信息获取指令的情况下，从关联审核方获取第一申请信息。

可选地，其中，项目申请请求携带有申请方针对待审核项目的申请类型；

对应地，获取模块1604被进一步配置为：在申请方的第一申请信息被预先存储在关联审核方的情况下，根据申请类型和待审核项目的项目属性，确定申请方是否满足待审核项目的申请条件；若是，向申请方发送信息获取请求。

可选地，第一生成模块1606被进一步配置为：在各初始项目申请表中添加第一申请信息，得到各目标审核方对应的项目申请表。

可选地，第一生成模块1606被进一步配置为：根据各初始项目申请表的信息标签，确定对应的第一申请信息；对第一申请信息进行对应的格式转换，在信息标签对应的信息域中条件转换后的第一申请信息，得到各目标审核方对应的项目申请表。

可选地，第一生成模块1606被进一步配置为：在各初始项目申请表中添加第一申请信息，得到各目标审核方对应的第一项目申请表；将各第一项目申请表发送至申请方；接收申请方发送的各第一项目申请表对应的第二申请信息；在各第一项目申请表中添加对应的第二申请信息，得到各目标审核方对应的项目申请表。

可选地，该装置还包括：第三接收模块，被配置为在未接收到申请方反馈的信息获取指令的情况下，将各目标审核方对应的初始项目申请表发送至申请方；接收申请方发送的第一申请信息。

可选地，该装置还包括：第二生成模块，被配置为接收各初始项目申请表对应的第二申请信息；基于第一申请信息和各初始项目申请表对应的第二申请信息，生成各目标审核方对应的项目申请表。

可选地，该装置还包括：转发模块，被配置为接收各目标审核方发送的审核结果，并将各审核结果发送至申请方。

本说明书实施例中，接收申请方发送的项目申请请求，其中，项目申请请求针对于目标审核方提供的待审核项目，目标审核方为多个审核方中至少一个；在申请方的第一申请信息被预先存储的情况下，获取第一申请信息；基于第一申请信息，生成各目标审核方对应的项目申请表；将各项目申请表发送至对应的目标审核方。由于申请方的申请信息具有较高的重复性，在此基础上获取预先存储的申请信息，并对应填写至各项目申请表中，高效完成对多个审核方的提交，减少了申请方重复基于申请信息生成项目申请表，简化了各项目申请表提交审核方的繁复过程，缩短了项目申请周期，提升了项目申请的效率，提升了项目申请的信息安全性，提升了用户体验。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于多方项目批量申请装置而言，由于其基本相似于多方项目批量申请方法实施例，所以描述得比较简单，相关之处参见多方项目批量申请方法实施例的部分说明即可。

与上述方法实施例相对应，本说明书还提供了多方项目批量申请装置实施例，图17示出了本说明书一个实施例提供的另一种多方项目批量申请装置的结构示意图。如图17所示，该装置应用于目标审核方，目标审核方为项目申请平台对应的多个审核方中至少一个，该装置包括：

第二接收模块1702，被配置为接收项目申请平台发送的对应的项目申请表，其中，项目申请表是基于申请方的第一申请信息生成的，第一申请信息是在第一申请信息被预先存储的情况下获取的。

可选地，该装置还包括：审核模块，被配置为根据项目申请表，确定审核结果，将审核结果发送至项目申请平台。

可选地，审核模块被进一步配置为：从项目申请平台获取来自关联审核方的申请方的行为数据；根据项目申请表和行为数据，确定审核结果。

本说明书实施例中，接收项目申请平台发送的对应的项目申请表，其中，项目申请表是基于申请方的第一申请信息生成的，第一申请信息是在第一申请信息被预先存储的情况下获取的。由于申请方的申请信息具有较高的重复性，在此基础上获取预先存储的申请信息，并对应填写至各项目申请表中，高效完成对多个审核方的提交，减少了申请方重复基于申请信息生成项目申请表，简化了各项目申请表提交审核方的繁复过程，缩短了项目申请周期，提升了项目申请的效率，提升了项目审核的信息安全性，提升了用户体验。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于多方项目批量申请装置而言，由于其基本相似于多方项目批量申请方法实施例，所以描述得比较简单，相关之处参见多方项目批量申请方法实施例的部分说明即可。

与上述方法实施例相对应，本说明书还提供了多方项目批量申请系统实施例，图18示出了本说明书一个实施例提供的一种多方项目批量申请系统的结构示意图。如图18所示，该系统包括申请方、项目申请平台和项目申请平台对应的至少一个目标审核方，该系统包括：

申请方1802，用于发送针对目标审核方1806提供的待审核项目的项目申请请求；

项目申请平台1804，用于接收项目申请请求，在申请方1802的第一申请信息被预先存储的情况下，获取第一申请信息，基于第一申请信息，生成各目标审核方1806对应的项目申请表，将各项目申请表发送至对应的目标审核方1806；

目标审核方1806，用于接收项目申请平台1804发送的对应的项目申请表。

可选地，目标审核方1806，还用于根据项目申请表，确定审核结果，将审核结果发送至项目申请平台1804；

项目申请平台1804，用于接收各目标审核方1806发送的审核结果，将各审核结果发送至申请方1802。

可选地，目标审核方1806，还用于从项目申请平台1804获取来自关联审核方的申请方1802的行为数据，根据项目申请表和行为数据，确定审核结果，将审核结果发送至项目申请平台1804。

本说明书实施例中，申请方，用于发送针对目标审核方提供的待审核项目的项目申请请求；项目申请平台，用于接收项目申请请求，在申请方的第一申请信息被预先存储的情况下，获取第一申请信息；基于第一申请信息，生成各目标审核方对应的项目申请表；将各项目申请表发送至对应的目标审核方；目标审核方，用于接收项目申请平台发送的对应的项目申请表。由于申请方的申请信息具有较高的重复性，在此基础上获取预先存储的申请信息，并对应填写至各项目申请表中，高效完成对多个审核方的提交，减少了申请方重复基于申请信息生成项目申请表，简化了各项目申请表提交审核方的繁复过程，缩短了项目申请周期，提升了项目申请的效率，提升了项目申请的信息安全性，提升了用户体验。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于多方项目批量申请系统而言，由于其基本相似于多方项目批量申请方法实施例，所以描述得比较简单，相关之处参见多方项目批量申请方法实施例的部分说明即可。

图19示出了本说明书一个实施例提供的一种计算设备的结构框图。该计算设备1900的部件包括但不限于存储器1910和处理器1920。处理器1920与存储器1910通过总线1930相连接，数据库1950用于保存数据。

计算设备1900还包括接入设备1940，接入设备1940使得计算设备1900能够经由一个或多个网络1960通信。这些网络的示例包括公用交换电话网(PSTN，PublicSwitchedTelephone Network)、局域网(LAN，LocalAreaNetwork)、广域网(WAN，WideAreaNetwork)、个域网(PAN，PersonalArea Network)或诸如因特网的通信网络的组合。接入设备1940可以包括有线或无线的任何类型的网络接口(例如，网络接口卡(NIC，network interface controller))中的一个或多个，诸如IEEE802.11无线局域网(WLAN，Wireless Local Area Network)无线接口、全球微波互联接入(Wi-MAX，WorldwideInteroperability for Microwave Access)接口、以太网接口、通用串行总线(USB，Universal Serial Bus)接口、蜂窝网络接口、蓝牙接口、近场通信(NFC，Near FieldCommunication)。

在本说明书的一个实施例中，计算设备1900的上述部件以及图19中未示出的其他部件也可以彼此相连接，例如通过总线。应当理解，图19所示的计算设备结构框图仅仅是出于示例的目的，而不是对本说明书范围的限制。本领域技术人员可以根据需要，增添或替换其他部件。

计算设备1900可以是任何类型的静止或移动计算设备，包括移动计算机或移动计算设备(例如，平板计算机、个人数字助理、膝上型计算机、笔记本计算机、上网本等)、移动电话(例如，智能手机)、可佩戴的计算设备(例如，智能手表、智能眼镜等)或其他类型的移动设备，或者诸如台式计算机或个人计算机(PC，Personal Computer)的静止计算设备。计算设备1900还可以是移动式或静止式的服务器。

其中，处理器1920用于执行如下计算机可执行指令，该计算机可执行指令被处理器执行时实现上述多方项目批量申请方法的步骤。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于计算设备实施例而言，由于其基本相似于多方项目批量申请方法实施例，所以描述得比较简单，相关之处参见多方项目批量申请方法实施例的部分说明即可。

本说明书一实施例还提供一种计算机可读存储介质，其存储有计算机可执行指令，该计算机可执行指令被处理器执行时实现上述多方项目批量申请方法的步骤。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于计算机可读存储介质实施例而言，由于其基本相似于多方项目批量申请方法实施例，所以描述得比较简单，相关之处参见多方项目批量申请方法实施例的部分说明即可。

本说明书一实施例还提供一种计算机程序，其中，当所述计算机程序在计算机中执行时，令计算机执行上述多方项目批量申请方法的步骤。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于计算机程序实施例而言，由于其基本相似于多方项目批量申请方法实施例，所以描述得比较简单，相关之处参见多方项目批量申请方法实施例的部分说明即可。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

所述计算机指令包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，RandomAccess Memory)、电载波信号、电信信号以及软件分发介质等。

需要说明的是，上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定都是本说明书实施例所必须的。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。

以上公开的本说明书优选实施例只是用于帮助阐述本说明书。可选实施例并没有详尽叙述所有的细节，也不限制该发明仅为所述的具体实施方式。显然，根据本说明书实施例的内容，可作很多的修改和变化。本说明书选取并具体描述这些实施例，是为了更好地解释本说明书实施例的原理和实际应用，从而使所属技术领域技术人员能很好地理解和利用本说明书。本说明书仅受权利要求书及其全部范围和等效物的限制。