CN111784262A - 物流平台司机和车辆的数据管理方法、装置以及存储介质 - Google Patents

Abstract

本申请公开了一种物流平台司机和车辆的数据管理方法、装置以及存储介质。其中，该方法包括：接收用户在客户端输入的司机或者车辆唯一的资质标识信息；根据资质标识信息判断是否存在与司机或者车辆对应的主数据，其中主数据包含与司机或者车辆的信息相关的多个数据项，并且主数据由审核人员对多个数据项审核通过后生成；以及在与司机或者车辆对应的主数据不存在的情况下，从客户端接收用户录入的与司机或者车辆的信息相关的多个数据项并进行审核，根据审核结果生成主数据。

Description

物流平台司机和车辆的数据管理方法、装置以及存储介质

技术领域

本申请涉及物流和互联网技术领域，特别是涉及一种物流平台司机和车辆的数据管理方法、装置以及存储介质。

背景技术

随着互联网的发展，“物流+互联网”赋能模式的不断推进，以业务协同为基础的共享式物流云服务平台内入驻的司机、车辆因业务原因可以从属多个不同企业，不同企业在引入司机、车辆时，需要对信息进行审核。现有的平台维护一套基础数据并提供给平台内用户使用，这类数据基本都是枚举型数据，行业内称之为枚举型主数据，即数据都是可预期、有限且可枚举的。对于非预期、不可枚举且随业务发生而形成的数据，平台运营者没办法提前预知和枚举，只能在业务发生时由平台运营者实时维护，这即影响平台用户使用体验与感受，也增加了平台运营成本。此外，现有的物流平台也无法实现司机和车辆的数据共建共享，因此也会增加平台的运营成本。

针对上述的现有技术中存在的在物流领域对于非预期、不可枚举且随业务发生而形成的司机或车辆的数据维护难度会增加，并且无法实现数据的共建共享，因此影响平台用户使用体验的技术问题，目前尚未提出有效的解决方案。

发明内容

本公开的实施例提供了一种物流平台司机和车辆的数据管理方法、装置以及存储介质，以至少解决现有技术中存在的在物流领域对于非预期、不可枚举且随业务发生而形成的司机或车辆的数据维护难度会增加，并且无法实现数据的共建共享，因此影响平台用户使用体验的技术问题。

根据本公开实施例的一个方面，提供了一种物流平台司机和车辆的数据管理方法，包括：接收用户在客户端输入的司机或者车辆唯一的资质标识信息；根据资质标识信息判断是否存在与司机或者车辆对应的主数据，其中主数据包含与司机或者车辆的信息相关的多个数据项，并且主数据由审核人员对多个数据项审核通过后生成；以及在与司机或者车辆对应的主数据不存在的情况下，从客户端接收用户录入的与司机或者车辆的信息相关的多个数据项并进行审核，根据审核结果生成主数据。

根据本公开实施例的另一个方面，还提供了一种存储介质，存储介质包括存储的程序，其中，在程序运行时由处理器执行以上任意一项所述的方法。

根据本公开实施例的另一个方面，还提供了一种物流平台司机和车辆的数据管理装置，应用于物流平台，包括：数据接收模块，用于接收用户在客户端输入的司机或者车辆唯一的资质标识信息；数据搜索模块，用于根据资质标识信息判断是否存在与司机或者车辆对应的主数据，其中主数据包含与司机或者车辆的信息相关的多个数据项，并且主数据由审核人员对多个数据项审核通过后生成；以及数据审核模块，用于在与司机或者车辆对应的主数据不存在的情况下，从客户端接收用户录入的与司机或者车辆的信息相关的多个数据项并进行审核，根据审核结果生成主数据。

根据本公开实施例的另一个方面，还提供了一种物流平台司机和车辆的数据管理装置，应用于物流平台，包括：处理器；以及存储器，与处理器连接，用于为处理器提供处理以下处理步骤的指令：接收用户在客户端输入的司机或者车辆唯一的资质标识信息；根据资质标识信息判断是否存在与司机或者车辆对应的主数据，其中主数据包含与司机或者车辆的信息相关的多个数据项，并且主数据由审核人员对多个数据项审核通过后生成；以及在与司机或者车辆对应的主数据不存在的情况下，从客户端接收用户录入的与司机或者车辆的信息相关的多个数据项并进行审核，根据审核结果生成主数据。

在本公开实施例中，平台系统可以根据资质标识信息判断是否存在对应的主数据，进而判断所要入驻的司机或者车辆是否已经完成审核入驻。在没有入驻的情况下，提示用户输入相关的数据项并由平台进行审核，审核通过后生成该主数据完成入驻。该主数据是经过审核的且可以代表司机或者车辆的资质，因此任何企业在该平台引入已入驻司机或者车辆的过程中可以借用主数据，不需要进行反复审核，节省了大量时间且更加可靠。此外，对于非预期、不可枚举(面向范围更广)的司机或者车辆经过审核后都可以在该平台完成入驻，因此并不会增加平台的运营负担。通过主数据可以将平台上司机或者车辆的数据标准统一化，并且可以实现数据的共建共享。因此解决了现有技术中存在的在物流领域对于非预期、不可枚举且随业务发生而形成的司机或车辆的数据维护难度会增加，并且无法实现数据的共建共享，因此影响平台用户使用体验的技术问题。

附图说明

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

图1是用于实现根据本公开实施例1所述的方法的计算设备的硬件结构框图；

图2是根据本公开实施例1所述的物流平台司机和车辆的数据管理系统的示意图；

图3是根据本公开实施例1所述的服务器功能模块示意图；

图4是根据本公开实施例1的第一个方面所述的物流平台司机和车辆的数据管理方法的流程示意图；

图5是根据本公开实施例1具体实例的流程图；

图6是根据本公开实施例2所述的物流平台司机和车辆的数据管理装置的示意图；以及

图7是根据本公开实施例3所述的物流平台司机和车辆的数据管理装置的示意图。

具体实施方式

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

需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

实施例1

根据本实施例，还提供了一种物流平台司机和车辆的数据管理方法实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

本实施例所提供的方法实施例可以在服务器或者类似的计算设备中执行。图1示出了一种用于实现物流平台司机和车辆的数据管理方法的计算设备的硬件结构框图。如图1所示，计算设备可以包括一个或多个处理器(处理器可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)、用于存储数据的存储器、以及用于通信功能的传输装置。除此以外，还可以包括：显示器、输入/输出接口(I/O接口)、通用串行总线(USB)端口(可以作为I/O接口的端口中的一个端口被包括)、网络接口、电源和/或相机。本领域普通技术人员可以理解，图1所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，计算设备还可包括比图1中所示更多或者更少的组件，或者具有与图1所示不同的配置。

应当注意到的是上述一个或多个处理器和/或其他数据处理电路在本文中通常可以被称为“数据处理电路”。该数据处理电路可以全部或部分的体现为软件、硬件、固件或其他任意组合。此外，数据处理电路可为单个独立的处理模块，或全部或部分的结合到计算设备中的其他元件中的任意一个内。如本公开实施例中所涉及到的，该数据处理电路作为一种处理器控制(例如与接口连接的可变电阻终端路径的选择)。

存储器可用于存储应用软件的软件程序以及模块，如本公开实施例中的物流平台司机和车辆的数据管理方法对应的程序指令/数据存储装置，处理器通过运行存储在存储器内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的应用程序的物流平台司机和车辆的数据管理方法。存储器可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器可进一步包括相对于处理器远程设置的存储器，这些远程存储器可以通过网络连接至计算设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

传输装置用于经由一个网络接收或者发送数据。上述的网络具体实例可包括计算设备的通信供应商提供的无线网络。在一个实例中，传输装置包括一个网络适配器(NetworkInterfaceController，NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输装置可以为射频(Radio Frequency，RF)模块，其用于通过无线方式与互联网进行通讯。

显示器可以例如触摸屏式的液晶显示器(LCD)，该液晶显示器可使得用户能够与计算设备的用户界面进行交互。

此处需要说明的是，在一些可选实施例中，上述图1所示的计算设备可以包括硬件元件(包括电路)、软件元件(包括存储在计算机可读介质上的计算机代码)、或硬件元件和软件元件两者的结合。应当指出的是，图1仅为特定具体实例的一个实例，并且旨在示出可存在于上述计算设备中的部件的类型。

图2是根据本实施例所述的物流平台司机和车辆的数据管理系统的示意图。参照图2所示，该系统包括：物流平台系统的服务器200以及用户的终端设备100，其中终端设备100上运行有与该物流平台系统对应的客户端程序，例如APP。司机或者拥有车辆的用户可以利用客户端访问系统的服务器200，进行车辆或者司机信息的录入，然后由平台进行审核最终完成平台入驻。并且企业也可以利用客户端访问该平台服务器，选择司机或者车辆进行引进。此外，该系统还包括云端数据库300，云数据库用来存储司机或者车辆的数据。并且图3示出了服务器200的功能模块示意图，包括：资质证照业务主数据管理模块、资质证照录入模块、资质证照提交模块、资质证照审核模块、资质证照更新模块。此外，该系统例如可以是SaaS平台架构的。需要说明的是，系统中的服务器200以及终端设备100均可适用上面所述的硬件结构。

在上述运行环境下，根据本实施例的第一个方面，提供了一种物流平台司机和车辆的数据管理方法，该方法由图2中所示的服务器200实现。图4示出了该方法的流程示意图，参考图4所示，该方法包括：

S402：接收用户在客户端输入的司机或者车辆唯一的资质标识信息；

S404：根据资质标识信息判断是否存在与司机或者车辆对应的主数据，其中主数据包含与司机或者车辆的信息相关的多个数据项，并且主数据由审核人员对多个数据项审核通过后生成；以及

S406：在与司机或者车辆对应的主数据不存在的情况下，从客户端接收用户录入的与司机或者车辆的信息相关的多个数据项并进行审核，根据审核结果生成主数据。

正如背景技术中所述的，随着互联网的发展，“物流+互联网”赋能模式的不断推进，以业务协同为基础的共享式物流云服务平台内入驻的司机、车辆因业务原因可以从属多个不同企业，不同企业在引入司机、车辆时，需要对信息进行审核。现有的平台维护一套基础数据并提供给平台内用户使用，这类数据基本都是枚举型数据，行业内称之为枚举型主数据，即数据都是可预期、有限且可枚举的。对于非预期、不可枚举且随业务发生而形成的数据，平台运营者没办法提前预知和枚举，只能在业务发生时由平台运营者实时维护，这即影响平台用户使用体验与感受，也增加了平台运营成本。此外，现有的物流平台也无法实现司机和车辆的数据共建共享，因此也会增加平台的运营成本。

针对背景技术中存在的技术问题，具体地，本实施例技术方案在步骤S402中，服务器200首先接收用户在客户端输入的司机或者车辆唯一的资质标识信息。例如物流公司(用户)在该平台进行入驻的过程中，用户可以利用该平台的客户端(终端设备100上运行的该平台的客户端)输入需要入驻的司机或者车辆唯一的资质标识信息，其中该资质标识信息是司机或者车辆唯一标识，例如：司机的资质标识信息可以是从业资格证的证照编号，车辆的资质标识信息可以是运营证的证照编号。在这种情况下，服务器200接收该资质标识信息。

进一步地，在步骤S404中，服务器200的资质证照业务主数据管理模块根据资质标识信息判断是否存在与司机或者车辆对应的主数据。其中主数据包含与司机或者车辆的信息相关的多个数据项，例如：资质证照编号(对应于资质标识信息)、资质证照名称、所有/持证人、发证日期、发证机构、有效期等数据项。在司机或者车辆首次入驻的过程中，服务器200通过资质证照录入模块接收用户(例如司机)录入的上述多个数据项，然后通过资质证照提交模块提交至平台审核人员，然后通过资质证照审核模块对用户录入的多个数据项进行审核，审核通过后生成该主数据。在判断是否存在与司机或者车辆对应的主数据的过程中，服务器200例如可以根据接收到的资质标识信息在云数据库中进行搜索，判断是否存在与该资质标识信息对应的主数据，即判断所要入驻登记的车辆或者司机是否在之前已经完成入驻审核。并且，不同企业在该平台引入司机或者车辆的过程中，由于平台维护有一份司机或者车辆资质证照数据作为主数据，并保证该主数据在平台内唯一且最新，从而可以实现平台内、企业间司机、车辆资质证照数据在平台内共享、复用与传递。

最终，在步骤S206中，在与司机或者车辆对应的主数据不存在的情况下(即该司机或者车辆没有经过入驻审核)，服务器200从客户端接收用户录入的与司机或者车辆的信息相关的多个数据项，然后发送至审核人员进行审核，在审核通过的情况下生成对应的主数据，完成司机或者车辆的入驻操作。

从而通过这种方式，平台系统可以根据资质标识信息判断是否存在对应的主数据，进而判断所要入驻的司机或者车辆是否已经入驻。在没有入驻的情况下，用户可以输入相关的数据项并由平台进行审核，审核通过后生成该主数据完成入驻。该主数据是经过审核的且可以代表司机或者车辆的资质，因此任何企业在该平台引入已入驻司机或者车辆的过程中可以借用该主数据，不需要进行反复审核，节省了大量时间且更加可靠。此外，对于非预期、不可枚举(面向范围更广)的司机或者车辆经过审核后都可以在该平台完成入驻，因此并不会增加平台的运营负担。通过主数据可以将平台上司机或者车辆的数据标准统一化，并且可以实现数据的共建共享。因此解决了现有技术中存在的在物流领域对于非预期、不可枚举且随业务发生而形成的司机或车辆的数据维护难度会增加，并且无法实现数据的共建共享，因此影响平台用户使用体验的技术问题。

可选地，该方法还包括：在与司机或者车辆对应的主数据存在的情况下，将主数据发送至客户端进行展示。

具体地，在服务器200根据资质标识信息判断存在与司机或者车辆对应的主数据，即司机或者车辆完成入驻审核，则服务器200将主数据反馈至客户端进行展示。从而，用户可以查看与车辆相关的信息。

可选地，将主数据发送至客户端进行展示，还包括：设置主数据的状态为已认证状态。具体地，在将主数据发送至客户端进行展示的同时设置主数据的状态为已认证状态，即标识该主数据是经过审核的，从而用户可以更加直观的确定该数据的状态。

可选地，将从客户端接收用户录入的与司机或者车辆的信息相关的多个数据项设置为未认证状态。

具体地，将从客户端接收用户录入的与司机或者车辆的信息相关的多个数据项，设置该多个数据项的认证状态为未认证状态，服务器200可以根据未认证的多个数据项直接生成待审核数据，然后发送至审核人员进行审核。

可选地，审核通过后生成主数据，服务器200还将该主数据保存至云端数据库300。

可选地，该方法还包括：从客户端接收用户输入的用于变更数据项的更新数据并进行审核；以及在审核通过的情况下，利用更新数据对主数据进行更新。

具体地，用户还可以对主数据中的数据项进行更新，例如：资质证照的有效期需要进行更新，在这种情况下服务器200从客户端接收用户输入的用于变更数据项的更新数据，然后生成待审核数据发送至平台进行审核。在审核通过的情况下，服务器200通过资质证照更新模块利用更新数据对主数据进行更新，即将主数据中的有效期数据项进行更新。从而可以对主数据项进行更新，保证了信息的有效性。

可选地，在对主数据更新后，服务器200利用更新后的主数据对使用主数据的对象的本地数据进行更新。例如：企业1引用过车辆1，则企业1的本地会保存有车辆1的相关数据，在车辆1的主数据更新后，服务器200可以对企业1本地的关于车辆1的相关数据进行更新，从而保证企业本地数据的有效性。

可选地，从客户端接收用户录入的与司机或者车辆的信息相关的多个数据项并进行审核，包括：利用从监管部门获取的司机或者车辆的信息对多个数据项进行审核。

具体地，在从客户端接收用户录入的与司机或者车辆的信息相关的多个数据项并进行审核的操作中，平台可以从监管部门获取与司机或者车辆相关的信息，例如：从运营部门获取车辆的运营资质信息(例如运营证)。然后将该信息与用户录入的与司机或者车辆的信息相关的多个数据项(输入的运营证的编号)进行比对，进而完成对数据的审核。从而可以提高平台数据的可信度。并且，多个企业在引入车辆或司机的过程中，不需要每个企业都去监管部门获取信息，而是共享平台提供的信息，因此可以节省人力物力，提升用户体验效果。

可选地，用户录入的与司机或者车辆的信息相关的多个数据项包括司机或者车辆的资质证照图像，方法还包括：根据资质证照图像对用户录入的与司机或者车辆的信息相关的多个数据项进行核对。

具体地，用户录入的与司机或者车辆的信息相关的多个数据项包括司机或者车辆的资质证照图像，例如：用户在录入信息的过程中会上传资质证照的照片，并同时还会录入相关的数据，例如：证照的编号。在这种情况下，服务器200可以识别资质证照图像中的信息(例如采用现有技术中的图像识别方法)，然后利用识别的信息对用户录入的与司机或者车辆的信息相关的多个数据项进行核对。即：平台经营者根据资质证照的照片，核对资质证照的申报数据并修正错误的录入数据。从而，进一步地保证了信息的准确性。

在一个具体实例中，参考图5的流程图，具体流程如下：

S10：录入资质证照编号(对应于资质标识消息)。

资质证照一般都有一个统一命名且具有一定编码规则的唯一编码，用于唯一识别该资质证照。用户只需要对照资质照将其唯一编号录入。

S20：根据该资质证照编号，获取资质证照的业务主数据信息(即对应于上述的主数据)或录入资质证照的数据(对应于多个数据项)。

为解决相同资质证照不同用户提交，平台经营者需要多次重复审核与验证问题，该实施例中，通过基于平台经营者第一次审核通过的资质证照数据构建了资质证照业务主数据，用于确保平台每份资质证照都经过一次审核与人工验证。

每份审核经过的资质证照，都会在云端数据库中有且唯一保留一份该资质证照数据，即该资质证照的业务主数据，每当用户输入资质证照编号时，都有检查云端数据库中是否存该资质证照的业务主数据，具体方法如下：

S21：根据录入的资质证照编号，获取该资质证照的业务主数据。

以录入的资质证照编号为唯一条件，向云端数据库查询该资质证照业务主数据，如果存该编号对应的资质证照业务主数据，则返回该资质证照业务主数据并执行S22，否则返回空内容并执行S23。

S22：将返回的资质证照业务主数据展示给用户查看，并标识该资质证照已认证。

S23：提示用户继续录入该资质证照的数据，并标识该资质证照未认证。

S30：根据资质证照的业务主数据获取结果判断该资质证照数据是否提交平台经营者审核(审核人员)。

该实施例中，在用户保存资质证照数据时，软件会根据该资质证照当前的认证状态来决定是否需要提交平台经营者审核。如果当前认证状态为未认证，则软件会自动生成资质证审核申请并提交平台经营者。

S31：判断当前资质证照是新增还是变更，如果是变更跳转到S33，否则执行S32。

S32：判断当前资质证照获取状态为系统获取还是手工录入。如果是系统获取，则资质证照数据仅保存于并跳转到S50，否则跳转到S33。

S33：根据当前录入或变更的资质证照数据，按约定要求生成待审核的资质证照业务主数据。

该实施例中，在用户保存资质证照数据时，系统会自动生成一份待审核的资质证照业务主数据并申请平台审核，包括：资质证照编号、资质证照名称、所有/持证人、发证日期、发证机构、有效期等数据项。

S40：根据平台经营者审核该资质证照数据的结果生成该资质证照的业务主数据。

该实施例中，平台经营者根据该资质证照审批申请进行审核，如果审核通过，则生成该资质证照的业务主数据，存存储于云数据库中。

S41：平台经营者根据资质证照的照片，核对资质证照的申报数据并修正错误的申报数据。

S42：系统判断资质证照申报数据的申报类型，如果是新申请，则系统以审核通过的资质证照数据作为该资质证照的业务主数据。如果是变更申请，则系统用审核通过的资质证照数据更新该资质证照的业务主数据。

S43：系统用审核通过的资质证照数据，更新申请人及使用该资质证照业务主数据的用户本地数据，以维持该资质证照业务主数据与使用该资质证照业务主数据的用户本地数据的一致性。

S50：结束

从而，根据资质证照的有效性与唯一性关联主数据，并且相同的资质证照不用重复审核。

此外，参考图1所示，根据本实施例的第二个方面，提供了一种存储介质。所述存储介质包括存储的程序，其中，在所述程序运行时由处理器执行以上任意一项所述的方法。

从而根据本实施例，平台系统可以根据资质标识信息判断是否存在对应的主数据，进而判断所要入驻的司机或者车辆是否已经入驻。在没有入驻的情况下，用户可以输入相关的数据项并由平台进行审核，审核通过后生成该主数据完成入驻。该主数据是经过审核的且可以代表司机或者车辆的资质，因此任何企业在该平台引入已入驻司机或者车辆的过程中可以借用该主数据，不需要进行反复审核，节省了大量时间且更加可靠。此外，对于非预期、不可枚举(面向范围更广)的司机或者车辆经过审核后都可以在该平台完成入驻，因此并不会增加平台的运营负担。通过主数据可以将平台上司机或者车辆的数据标准统一化，并且可以实现数据的共建共享。因此解决了现有技术中存在的在物流领域对于非预期、不可枚举且随业务发生而形成的司机或车辆的数据维护难度会增加，并且无法实现数据的共建共享，因此影响平台用户使用体验的技术问题。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

实施例2

图6示出了根据本实施例所述的物流平台司机和车辆的数据管理装置600，该装置600与根据实施例1的第一个方面所述的方法相对应。参考图6所示，该装置600包括：数据接收模块610，用于接收用户在客户端输入的司机或者车辆唯一的资质标识信息；数据搜索模块620，用于根据资质标识信息判断是否存在与司机或者车辆对应的主数据，其中主数据包含与司机或者车辆的信息相关的多个数据项，并且主数据由审核人员对多个数据项审核通过后生成；以及数据审核模块610，用于在与司机或者车辆对应的主数据不存在的情况下，从客户端接收用户录入的与司机或者车辆的信息相关的多个数据项并进行审核，根据审核结果生成主数据。

可选地，装置600还包括：数据展示模块，用于在与司机或者车辆对应的主数据存在的情况下，将主数据发送至客户端进行展示。

可选地，数据展示模块，包括：状态展示子模块，用于将主数据发送至客户端进行展示，还包括：设置主数据的状态为已认证状态。

可选地，所述装置600还包括：认证模块，用于将从客户端接收用户录入的与司机或者车辆的信息相关的多个数据项设置为未认证状态。

可选地，装置600还包括：数据存储模块，用于审核通过后生成主数据，将所述主数据保存至云端数据库

可选地，装置600还包括：更新数据接收模块，用于从客户端接收用户输入的用于变更数据项的更新数据并进行审核；以及数据更新模块，用于在审核通过的情况下，利用更新数据对主数据进行更新。

可选地，装置600还包括：同步模块，用于利用更新后的主数据对使用主数据的对象的本地数据进行更新。

可选地，数据审核模块630，包括：审核子模块，用于利用从监管部门获取的司机或者车辆的信息对多个数据项进行审核。

可选地，用户录入的与司机或者车辆的信息相关的多个数据项包括司机或者车辆的资质证照图像，装置600还包括：核对模块，用于根据资质证照图像对用户录入的与司机或者车辆的信息相关的多个数据项进行核对。

从而根据本实施例，可以根据资质标识信息判断是否存在对应的主数据，进而判断所要入驻的司机或者车辆是否已经入驻。在没有入驻的情况下，用户可以输入相关的数据项并由平台进行审核，审核通过后生成该主数据完成入驻。该主数据是经过审核的且可以代表司机或者车辆的资质，因此任何企业在该平台引入已入驻司机或者车辆的过程中可以借用该主数据，不需要进行反复审核，节省了大量时间且更加可靠。此外，对于非预期、不可枚举(面向范围更广)的司机或者车辆经过审核后都可以在该平台完成入驻，因此并不会增加平台的运营负担。通过主数据可以将平台上司机或者车辆的数据标准统一化，并且可以实现数据的共建共享。因此解决了现有技术中存在的在物流领域对于非预期、不可枚举且随业务发生而形成的司机或车辆的数据维护难度会增加，并且无法实现数据的共建共享，因此影响平台用户使用体验的技术问题。

实施例3

图7示出了根据本实施例所述的物流平台司机和车辆的数据管理装置700，该装置700与根据实施例1的第一个方面所述的方法相对应。参考图7所示，该装置700包括：处理器710；以及存储器720，与处理器710连接，用于为处理器710提供处理以下处理步骤的指令：接收用户在客户端输入的司机或者车辆唯一的资质标识信息；根据资质标识信息判断是否存在与司机或者车辆对应的主数据，其中主数据包含与司机或者车辆的信息相关的多个数据项，并且主数据由审核人员对多个数据项审核通过后生成；以及在与司机或者车辆对应的主数据不存在的情况下，从客户端接收用户录入的与司机或者车辆的信息相关的多个数据项并进行审核，根据审核结果生成主数据。

可选地，存储器720还用于为处理器710提供处理以下处理步骤的指令：在与司机或者车辆对应的主数据存在的情况下，将主数据发送至客户端进行展示。

可选地，存储器720还用于为处理器710提供处理以下处理步骤的指令：将主数据发送至客户端进行展示，并设置主数据的状态为已认证状态。

可选地，存储器720还用于为处理器710提供处理以下处理步骤的指令：将主数据保存至云端数据库。

可选地，存储器720还用于为处理器710提供处理以下处理步骤的指令：从客户端接收用户输入的用于变更数据项的更新数据并进行审核；以及在审核通过的情况下，利用更新数据对主数据进行更新。

可选地，存储器720还用于为处理器710提供处理以下处理步骤的指令：利用更新后的主数据对使用主数据的对象的本地数据进行更新。

可选地，从客户端接收用户录入的与司机或者车辆的信息相关的多个数据项进行审核，包括：利用从监管部门获取的司机或者车辆的信息对多个数据项进行审核。

可选地，用户录入的与司机或者车辆的信息相关的多个数据项包括司机或者车辆的资质证照图像，并且存储器720还用于为处理器710提供处理以下处理步骤的指令：根据资质证照图像对用户录入的与司机或者车辆的信息相关的多个数据项进行核对。

从而根据本实施例，可以根据资质标识信息判断是否存在对应的主数据，进而判断所要入驻的司机或者车辆是否已经入驻。在没有入驻的情况下，用户可以输入相关的数据项并由平台进行审核，审核通过后生成该主数据完成入驻。该主数据是经过审核的且可以代表司机或者车辆的资质，因此任何企业在该平台引入已入驻司机或者车辆的过程中可以借用该主数据，不需要进行反复审核，节省了大量时间且更加可靠。此外，对于非预期、不可枚举(面向范围更广)的司机或者车辆经过审核后都可以在该平台完成入驻，因此并不会增加平台的运营负担。通过主数据可以将平台上司机或者车辆的数据标准统一化，并且可以实现数据的共建共享。因此解决了现有技术中存在的在物流领域对于非预期、不可枚举且随业务发生而形成的司机或车辆的数据维护难度会增加，并且无法实现数据的共建共享，因此影响平台用户使用体验的技术问题。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

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

在本申请所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，RandomAccessMemory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (10)

1.一种物流平台司机和车辆的数据管理方法，应用于物流平台，其特征在于，包括：

接收用户在客户端输入的司机或者车辆唯一的资质标识信息；

根据所述资质标识信息判断是否存在与所述司机或者车辆对应的主数据，其中所述主数据包含与所述司机或者车辆的信息相关的多个数据项，并且所述主数据由审核人员对所述多个数据项审核通过后生成；以及

在与所述司机或者车辆对应的主数据不存在的情况下，从所述客户端接收所述用户录入的与所述司机或者车辆的信息相关的多个数据项并进行审核，根据审核结果生成所述主数据。

2.根据权利要求1所述的方法，其特征在于，还包括：在与所述司机或者车辆对应的主数据存在的情况下，将所述主数据发送至所述客户端进行展示。

3.根据权利要求2所述的方法，其特征在于，将所述主数据发送至所述客户端进行展示，还包括：设置所述主数据的状态为已认证状态。

4.根据权利要求1所述的方法，其特征在于，还包括：将从所述客户端接收所述用户录入的与所述司机或者车辆的信息相关的多个数据项设置为未认证状态。

5.根据权利要求1所述的方法，其特征在于，审核通过后生成所述主数据，还包括：将所述主数据保存至云端数据库。

6.根据权利要求1所述的方法，其特征在于，还包括：

从所述客户端接收所述用户输入的用于变更所述数据项的更新数据并进行审核；以及

在审核通过的情况下，利用所述更新数据对所述主数据进行更新。

7.根据权利要求6所述的方法，其特征在于，还包括：利用更新后的主数据对使用所述主数据的对象的本地数据进行更新。

8.根据权利要求1所述的方法，其特征在于，从所述客户端接收所述用户录入的与所述司机或者车辆的信息相关的多个数据项并进行审核，包括：

利用从监管部门获取的所述司机或者车辆的信息对所述多个数据项进行审核。

9.根据权利要求1所述的方法，其特征在于，所述用户录入的与所述司机或者车辆的信息相关的多个数据项包括所述司机或者车辆的资质证照图像，所述方法还包括：

根据所述资质证照图像对所述用户录入的与所述司机或者车辆的信息相关的多个数据项进行核对。

10.一种存储介质，其特征在于，所述存储介质包括存储的程序，其中，在所述程序运行时由处理器执行权利要求1至9中任意一项所述的方法。

Images