库存数据对账方法及装置与流程

本申请涉及库存数据处理技术领域，特别是涉及库存数据对账方法及装置。

背景技术：

随着电子商务销售平台的不断完善，以及传统通信、移动通信等技术的快速发展，越来越多的人们通过网上购物的方式来获取自己所需的商品。为了满足买卖双方的需求，一些销售平台为一些特殊的业务对象(例如大家电等)提供了统一的物流服务(例如，阿里巴巴的“菜鸟物流宝”等等)，这种统一的物流服务一般被称为4PL。所谓4PL是指，平台方向第三方仓储及配送服务商采购仓库资源及配送资源，之后可以将这种资源包装成物流解决方案，在系统中进行发布，这样，商家可以根据自己的需求，定制平台提供的物流解决方案，并进行铺货等操作即可。也就是说，通过4PL，商家可以直接使用平台为其提供的仓库资源及配送资源，从而可以节约商家的成本，并且从仓库资源及配送资源角度讲，还可以起到节省资源，降低资源浪费的目的，此外，还可以从整体上提高交易平台的服务质量。

从以上4PL的定义可知，在该体系中，对于平台而言，仓储服务属于一种第三方的服务，可以将其称为“仓储服务提供方”，为便于描述，将其简称为“仓库方”，将交易平台中“菜鸟物流宝”等统一物流服务提供方称为“平台方”。

在具体的实现方案中，仓库方以及平台方各自都会维护各个业务对象的库存数据，因此，这种位于不同服务器的数据称为跨源数据。并且在实际应用中，通常是由平台方向商家或者买家用户表达业务对象的具体库存信息，而平台方的库存数据最初是从仓库方获知的，也即，商家将具体的业务对象入驻到仓库之后，仓库对其库存数据进行更新，并将该库存数据提供给平台方，此时，买家用户就可以在业务对象详情页面中查看到具体的库存数量信息。后续在买家 用户下单的过程中，通常又是由平台方首先将其库存数据进行锁定，并将通知给仓库，由仓库执行具体的发货操作，执行对仓库方库存数据进行扣减，再将该扣减事件通知给平台方，平台方再将对应的锁定数据转换为扣减，等等。以上过程称为跨源数据之间的数据同步。

但是，在现有技术中，由于需要在多系统之间进行交互，而对接仓库方的能力参差不齐，很多库存操作不能及时回传，因此，经常出现库存不准确，平台方的库存数据和仓库方的库存数据不一致等情况。例如，“天猫”大家电业务的案例：仓库方发现某货物损坏了，盘亏2台良品，但是由于没有上传给平台方，导致平台方认为还可以继续售卖，于是可能会产生对应的2笔交易发货单，但实际上仓库方已经无法发货，也即出现了超卖现象，等等。

为了避免出现上述问题，可以采用定期对账的方式，将仓库方以及平台方的库存数据进行对账，已及时发现两者之间的差异。但是，如果使用传统的对账方案，则通常是：通过人工的方式，将仓库方前一天的进销存账与平台方前一天的进销存账进行核对。这种方式至少存在以下问题：

首先，需要占用大量的人力资源，并且耗费很长的时间。其次，平台方的业务系统，每天要处理大量与仓库方交互的各类订单，下发、打包回传、确认出入库等状态的回传操作。如果在业务系统进行大数据的存储和比对，会对业务系统的处理性能产生影响。

技术实现要素：

本申请提供了库存数据对账方法及装置，可以避免对平台方具体业务的运行造成影响。

本申请提供了如下方案：

一种库存数据对账方法，包括：

对账服务器通过预置的数据存储引擎接收平台方业务服务器回流的第一账务信息，所述第一账务信息包括根据平台方第一库存数据库的库存变化生成的第一库存流水记录，以及根据所述第一库存数据库在指定时刻的状态生成的 第一库存快照；

从仓库方提供的仓库服务器中提取第二账务信息，所述第二账务信息包括根据仓库方第二库存数据库的库存变化生成的第二库存流水，以及根据所述第二库存数据库在所述指定时刻的状态生成的第二库存快照；

对所述第二账务信息进行解析，并上传到所述数据存储引擎；

在所述数据存储引擎中，将指定对账周期内的第一账务信息以及第二账务信息进行对比，确定两者之间的差异信息；

提供所述差异信息。

一种库存数据对账方法，包括：

平台方业务服务器确定第一账务信息，所述第一账务信息包括根据平台方第一库存数据库的库存变化生成的第一库存流水记录，以及根据所述第一库存数据库在指定时刻的状态生成的第一库存快照；

将所述第一账务信息回流到预置的数据存储引擎，以便对账服务器在将仓库服务器提供的第二账务信息进行解析并上传到所述数据存储引擎后，在所述数据存储引擎中，将指定对账周期内的第一账务信息以及第二账务信息进行对比，确定两者之间的差异信息；

其中，所述第二账务信息包括根据仓库方第二库存数据库的库存变化生成的第二库存流水，以及根据所述第二库存数据库在所述指定时刻的状态生成的第二库存快照。

一种库存数据对账方法，包括：

仓库服务器确定第二账务信息，所述第二账务信息包括根据仓库方第二库存数据库的库存变化生成的第二库存流水，以及根据所述第二库存数据库在所述指定时刻的状态生成的第二库存快照；

根据对账服务器指定的时间确定对账周期；

根据所述对账周期，将所述第二库存流水以及所述第二库存快照生成账务 文件，并保存到预置的仓库服务器，以便对账服务器从所述仓库服务器读取所述账务文件，进行解析后上传到预置的数据存储引擎，并在将平台方的第一账务信息回流到所述数据存储引擎后，在所述数据存储引擎中，将指定对账周期内的第一账务信息以及第二账务信息进行对比，确定两者之间的差异信息；

其中，所述第一账务信息包括根据平台方第一库存数据库的库存变化生成的第一库存流水，以及根据所述第一库存数据库在所述指定时刻的状态生成的第一库存快照。

一种库存数据对账装置，应用于对账服务器，包括：

第一账务信息接收单元，用于通过预置的数据存储引擎接收平台方业务服务器回流的第一账务信息，所述第一账务信息包括根据平台方第一库存数据库的库存变化生成的第一库存流水记录，以及根据所述第一库存数据库在指定时刻的状态生成的第一库存快照；

第二账务信息提取单元，用于从仓库方提供的仓库服务器中提取第二账务信息，所述第二账务信息包括根据仓库方第二库存数据库的库存变化生成的第二库存流水，以及根据所述第二库存数据库在所述指定时刻的状态生成的第二库存快照；

第二账务信息处理单元，用于对所述第二账务信息进行解析，并上传到所述数据存储引擎；

账务信息对比单元，用于在所述数据存储引擎中，将指定对账周期内的第一账务信息以及第二账务信息进行对比，确定两者之间的差异信息；

差异信息提供单元，用于提供所述差异信息。

一种库存数据对账装置，应用于平台方业务服务器，包括：

第一账务信息确定单元，用于确定第一账务信息，所述第一账务信息包括根据平台方第一库存数据库的库存变化生成的第一库存流水记录，以及根据所述第一库存数据库在指定时刻的状态生成的第一库存快照；

第一账务信息回流单元，用于将所述第一账务信息回流到预置的数据存储 引擎，以便对账服务器在将仓库服务器提供的第二账务信息进行解析并上传到所述数据存储引擎后，在所述数据存储引擎中，将指定对账周期内的第一账务信息以及第二账务信息进行对比，确定两者之间的差异信息；

其中，所述第二账务信息包括根据仓库方第二库存数据库的库存变化生成的第二库存流水，以及根据所述第二库存数据库在所述指定时刻的状态生成的第二库存快照。

一种库存数据对账装置，应用于仓库服务器，包括：

第二账务信息确定单元，用于确定第二账务信息，所述第二账务信息包括根据仓库方第二库存数据库的库存变化生成的第二库存流水，以及根据所述第二库存数据库在所述指定时刻的状态生成的第二库存快照；

对账周期确定单元，用于根据对账服务器指定的时间确定对账周期；

账务文件生成单元，用于根据所述对账周期，将所述第二库存流水以及所述第二库存快照生成账务文件，并保存到预置的仓库服务器，以便对账服务器从所述仓库服务器读取所述账务文件，进行解析后上传到预置的数据存储引擎，并在将平台方的第一账务信息回流到所述数据存储引擎后，在所述数据存储引擎中，将指定对账周期内的第一账务信息以及第二账务信息进行对比，确定两者之间的差异信息；

其中，所述第一账务信息包括根据平台方第一库存数据库的库存变化生成的第一库存流水，以及根据所述第一库存数据库在所述指定时刻的状态生成的第一库存快照。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请实施例，平台方以及仓库方的数据都可以上传到对账服务器的数据存储引擎，并利用该数据存储引擎实现对平台方以及仓库方的库存数据进行对账，避免两者长时间存在差异不被发现而导致的超卖等现象。并且，由独立的对账服务器在数据存储引擎中执行对账操作，因此，可以避免对平台方具体业务的运行造成影响。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的方法的流程图；

图2是本申请实施例提供的另一方法的流程图；

图3是本申请实施例提供的再一方法的流程图；

图4是本申请实施例提供的装置的示意图；

图5是本申请实施例提供的另一装置示意图；

图6是本申请实施例提供的再一装置的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。

在本申请实施例中，提供了在仓库方与平台方之间进行对账的解决方案。为了便于理解，下面首先从整体上对本申请实施例的实现方式进行介绍。

首先，本申请实施例在平台方提供了对账系统，该对账系统可以部署于平台方的服务器中，为了便于区分，本申请实施例中将对账系统所在的服务器称为“对账服务器”，将平台方用于执行具体业务的服务器称为“业务服务器”。需要说明的是，为了避免对平台方具体的业务运行造成影响，该对账服务器与业务服务器可以是不同的服务器。可以为该对账服务器提供一数据存储引擎，该数据存储引擎可以用于进行大数据存储、计算等操作。

另外，本申请实施例还提出了“对账周期”的概念，例如，可以以一天为一个对账周期，也就是说，可以每天在仓库方与平台方之间进行一次对账。

具体在进行对账时，可以基于双方的账务信息来进行，所谓的账务信息可以包括库存流水以及库存快照。其中，所谓的库存流水，是基于库存数据库中库存数据的变化而生成的。所谓的库存快照，也就是库存数据库中某个时刻的具体状态数据，例如，可以是0：00时刻的快照，等等。对于平台方以及仓库方而言，由于各自都维护有库存数据库(将平台方的库存数据库称为“第一库存数据库”，将仓库方的库存数据库称为“第二库存数据库”)，因此，可以分别获取到双方库存数据库中的库存流水以及同一时刻的库存快照，然后进行比对，以判断是否存在差异。

其中，关于平台方第一库存数据库中的账务信息，由于对账服务器位于平台方，因此，可以由平台方的业务服务器根据平台方第一库存数据库的库存变化生成第一库存流水记录，并根据第一库存数据库在指定时刻的状态生成第一库存快照，然后，将这种第一库存流水记录以及第一库存快照回流到账务服务器的数据存储引擎中进行保存。

具体实现时，关于平台方的账务信息，业务服务器可以实时回流到数据存储引擎，或者，为了进一步降低对业务服务器的影响，还可以采用定期向数据存储引擎回流的方式。例如，可以每个对账周期回流一次，并且，执行回流操作的时间可以是在业务服务器的“闲时”进行。如：假设对账周期为一天，则可以在每天凌晨2：00(或者也可以是其他时间)，将前一天产生的库存流水，以及指定时刻(例如，0：00等)的库存快照回流到数据存储引擎。另外，还可以将0：00之后2：00之前产生的库存流水也回流到数据存储引擎，这部分数据的作用会在后文中进行介绍。

而关于仓库方第二库存数据库中的账务信息，可以首先由仓库服务器将账务信息生成账务文件，并保存到仓库服务器中，例如，通过FTP(文件传输协议)服务器中，账务服务器可以定期通过访问该仓库服务器的方式，提取第二账务信息。例如，仍然假设以一天为一个对账周期，则仓库服务器可以每天生成一个账务文件，并保存到仓库服务器，账务服务器可以每天访问一次该仓库 服务器，抓取该账务文件，从中提取第二账务信息，并且最终可以上传到数据存储引擎。

其中，关于仓库方每个账务周期生成的账务文件，可以包括当前账务周期内的库存流水记录以及库存快照，或者，还可以包括当前账务周期之前和/或之后一定时间段(例如两个小时等)内的库存流水，也就是说，仓库服务器可以在每天的凌晨两点之后生成该账务文件，这样，该账务文件中可以包括前一天及其之前和/或之后两个小时的库存流水，这部分信息的作用在后文中会进行介绍。

总之，对于平台方的账务信息，可以由平台方业务服务器回流到账务系统的数据存储引擎，对于仓库方的账务信息，可以由仓库服务器提供账务文件，再由账务系统进行抓取并解析后，也上传到数据存储引擎。这样，就可以在该数据存储引擎中，对双方的账务信息进行比对，从而可以比对出两者之间的差异信息，进而就可以将该差异信息推送到具体的工单平台，由具体的工作人员对差异信息进行处理。

通过上述方式，可以实现对平台方以及仓库方的库存数据进行对账，避免两者长时间存在差异不被发现而导致的超卖等现象。并且，双方的账务信息都可以回流或者上传到数据存储引擎，由独立的对账服务器在数据存储引擎中执行对账操作，避免对平台方具体业务的运行造成影响。

可见，在本申请实施例中，涉及到的实体有：对账服务器、平台方业务服务器以及仓库服务器，三者相互配合，实现具体的对账操作。下面分别从者角度出发对具体的实现方式进行介绍。

实施例一

该实施例一首先从对账服务器的角度进行介绍。参见图1，该实施例一提供了一种库存数据对账方法，该方法可以包括以下步骤：

S101：对账服务器通过预置的数据存储引擎接收平台方业务服务器回流的第一账务信息，所述第一账务信息包括根据平台方第一库存数据库的库存变化生成的第一库存流水记录，以及根据所述第一库存数据库在指定时刻的状态生 成的第一库存快照；

如前文所述，平台方业务服务器可以通过多种方式将其第一账务信息回流到数据存储引擎。

S102：从仓库方提供的仓库服务器中提取第二账务信息，所述第二账务信息包括根据仓库方第二库存数据库的库存变化生成的第二库存流水，以及根据所述第二库存数据库在所述指定时刻的状态生成的第二库存快照；

对于仓库方的第二账务信息，可以由对账服务器从仓库方提供的仓库服务器中进行提取。具体实现时，如果以一天为对账周期，则对账服务器可以每天定时从仓库方提供的仓库服务器抓取仓库的账务文件，并保存到某指定第一服务器的固定目录下。

S103：对所述第二账务信息进行解析，并上传到所述数据存储引擎；

仓库方的账务信息格式与平台方往往是不同的，因此，在上传到数据存储引擎之前还可以进行解析。具体实现时，为了进一步降低对平台方具体业务系统产生影响，可以由另外一台服务器(第二服务器)用python的工程SCP(有安全机制的文件复制)第一服务器中该固定目录的文件，接下来，该第二服务器将账务文件进行解析，然后用数据存储引擎的上传接口，将第二账务信息上传到数据存储引擎的指定表的指定分区。

S104：在所述数据存储引擎中，将指定对账周期内的第一账务信息以及第二账务信息进行对比，确定两者之间的差异信息；

在将平台方以及仓库方的账务信息都上传到数据存储引擎后，就可以在数据存储引擎中进行对比。其中，具体进行对比时，可以基于同一对账周期内的数据进行对比。例如，在需要对5月1日的账务信息进行对账时，可以首先提取出5月1日00：00到5月2日00：00之间的第一库存信息以及第二库存信息，然后进行对比。如，假设平台方在5月1日的部分库存流水如表1所示：

表1

仓库方在5月1日的部分库存流水如表2所示：

表2

需要说明的是，针对同一个业务对象，平台方通常是通过账户来管理库存的(如良品：100，是指该业务对象在整个仓库的总量)，而仓库方是根据若干个库位进行库存管理的，如100件库存分布在10个库位，所以仓库方的流水是关联到库位上的。

另外需要说明的是，表1与表2中的库存流水具有关联性，也就是说，表1中某条记录可能是基于表2中的某条或者某几条记录产生的，表2中的记录也可能是基于表1中的某条或者某几条记录产生的，并且，这种具有关联性的记录，一般可以通过“订单编号”字段体现处理。例如，由以上表1以及表2可知，对于订单编号为“LBX001”的订单，在表1中存在一条与该订单相关的记录，在表2中存在两条与该订单相关的记录。基于该订单，具体的应用场景可以为：假设某买家用户购买了5件编号为“10001”的业务对象，此时，

平台方首先可以将该业务对象在第一库存数据库中的5件库存置为锁定状态，并通知仓库方进行出库；仓库方针对该订单执行出库操作，其中3件是从库位A31出库的，另外2件是从库位A32出库的。

因此，具体在进行双方库存流水的比对时，可以基于订单编号进行。例如，针对当前对账周期内第一库存流水的某条记录，可以取出其中的订单编号，然后在该对账周期内第二库存流水记录中查找该订单编号对应的记录，再将相同订单编号对应条目中的库存变化数量进行比对。例如，针对表1中的第一条记录，订单编号为“LBX001”，该记录中的库存变化数量为“-5”，表2中与该记录的订单编号相同的记录为第一条以及第二条，库存变化数量分别为“-3”和“-2”，数量之和也为“-5”，因此，针对该订单的库存账务信息不存在差异。也就是说，针对该订单，仓库方与平台方之间已经完成了库存数据的同步。

而针对表1中的第二条记录，订单编号为“LBX002”，该记录中的库存变化数量为“-5”，表2中与该记录的订单编号相同的记录为第三条以及第四条，库存变化数量分别为“-2”和“-2”，数量之和为“-4”，可见，针对该订单的库存账务信息，在平台方与仓库方之间存在差异。也就是说，针对该订单，仓库方与平台方之间可能尚未完成库存数据的同步。

另外，对于表1中的第三条记录，订单编号为“LBX003”，而表2中不存在与该订单编号对应的记录，此时，也证明两者之间存在差异。此外，还可能存在以下情况：表2中存在某订单编号的记录，而表1中不存在该订单编号对应的记录，等等。

总之，在进行对账时，确定出的差异信息可能有以下类型：

(1)平台方有流水、仓库方没有流水

(2)仓库方有流水、平台方没有流水

(3)仓库方、平台方都有流水，但数量不一致

通过本申请实施例，上述各种情况都可以核对出来，并且还可以对差异信息按照上述方式进行分类。

另外，对于库存快照，平台方与仓库方的库存数据格式可以是相同的，例如，如表3所示：

表3

因此，在进行库存快照的比对时，将双方的库存快照中各个字段上的具体取值进行比对即可。

S105：提供所述差异信息。

在确定出差异信息后，可以推送给工单平台，由相关的工作人员对差异信息进行进一步的核查处理，以尽量避免由于数据同步上的差异导致的超卖等现象。

需要说明的是，在本申请实施例中，是在同一对账周期内对平台方以及仓库方之间的库存数据进行对账，之所会产生对账周期的概念，是因为，双方的 数据同步操作通常是在一定的时间内执行的，例如，在某一方的库存数据发生变更后，会在一定的时间内(例如，数小时内等等)同步到另一方。

但是，本申请发明人在实现本申请的过程中还发现：不同异步系统处理数据有先后顺序，而且存在时间差的问题，导致在时间临界点出现伪差异的情况。例如，仓库方作业产生是23:59:59,回传到平台方的时间是00:00:02，在按日进行对账的情况下，双方的流水是不一致的，会产生差异。但实际上，这种差异可能并不会导致出现超卖等现象，而纯粹是由于对对账周期以及时间临界点的定义而产生的，因此，称为“伪差异”。另一方面，在实际应用中，仓库方经常会凌晨作业，仓库自身库存变更记录可能会隔几个小时甚至隔天才会同步到平台方，因此，如果是一天为对账周期，以00：00为时间临界点，则这种伪差异的现象则会非常多。如果每天都把这部分差异对出来，则需要平台方和仓库方提供大量的人力去核查这些伪差异，费时费力。

为此，在本申请实施例中，还提供了以下处理方式：在平台方以及仓库方提供账务信息时，除了当前对账周期内的账务信息，还可以包括当前对账周期之前以及之后一段时间的账务信息，例如，之前以及之后两个小时，等等。具体的，仍然假设对账周期为一天，每天00：00为时间临界点，则平台方可以在每天凌晨02：00之后再向数据存储引擎回流账务信息，这部分账务信息除了包括前一天的库存流水，还包括了从00：00到02：00之间的库存流水。类似的，仓库方也可以在每天凌晨02：00之后再生产账务文件，并向仓库服务器进行保存。

这样，对账服务器在进行账务信息的比对时，可以首先针对双方账务信息在当前对账周期内的部分进行比对，也即先对从5月1日00：01到5月2日00：00的库存流水进行对比，当发现差异信息后，再利用双方在4月30日22：00到5月1日00：00，以及5月2日00：00到02：00的数据，对这部分差异数据进行核查。

例如，在前述表1与表2中，订单编号为“LBX002”的记录在双方的库存流水中存在差异，而在仓库方5月2日00：00到02：00的库存流水中，发现存在该另一条关于该订单编号的记录，并且，之前相差的数量刚好与该记录中 的数量相同，则可以确定该差异为伪差异，不再向工单平台推送，这样，相关的工作人员将不会收到关于该伪差异的提示，减少工作人员的工作量。

实施例二

该实施例二从平台方业务服务器的角度进行描述。参见图2，该实施例二提供了一种库存数据对账方法，该方法可以包括以下步骤：

S201：平台方业务服务器确定第一账务信息，所述第一账务信息包括根据平台方第一库存数据库的库存变化生成的第一库存流水记录，以及根据所述第一库存数据库在指定时刻的状态生成的第一库存快照；

S202：将所述第一账务信息回流到预置的数据存储引擎，以便对账服务器在将仓库服务器提供的第二账务信息进行解析并上传到所述数据存储引擎后，在所述数据存储引擎中，将指定对账周期内的第一账务信息以及第二账务信息进行对比，确定两者之间的差异信息；

其中，所述第二账务信息包括根据仓库方第二库存数据库的库存变化生成的第二库存流水，以及根据所述第二库存数据库在所述指定时刻的状态生成的第二库存快照。

其中，为了避免出现大量的伪差异数据，所述回流到数据存储引擎的第一库存流水记录包括所述对账周期内的第一库存流水记录，以及对账周期之前和/或之后预置时间段内的第一库存流水记录。

实施例三

该实施例二从仓库方的仓库服务器的角度进行描述，参见图3，该实施例提供了一种库存数据对账方法，该方法可以包括以下步骤：

S301：仓库服务器确定第二账务信息，所述第二账务信息包括根据仓库方第二库存数据库的库存变化生成的第二库存流水，以及根据所述第二库存数据 库在所述指定时刻的状态生成的第二库存快照；

S302：根据对账服务器指定的时间确定对账周期；

S303：根据所述对账周期，将所述第二库存流水以及所述第二库存快照生成账务文件，并保存到预置的仓库服务器，以便对账服务器从所述仓库服务器读取所述账务文件，进行解析后上传到预置的数据存储引擎，并在将平台方的第一账务信息回流到所述数据存储引擎后，在所述数据存储引擎中，将指定对账周期内的第一账务信息以及第二账务信息进行对比，确定两者之间的差异信息；

其中，所述第一账务信息包括根据平台方第一库存数据库的库存变化生成的第一库存流水，以及根据所述第一库存数据库在所述指定时刻的状态生成的第一库存快照。

为了解决伪差异的问题，所述账务文件中的账务文件中包括对账周期内的第二库存流水记录，以及对账周期之前和/或之后预置时间段内的第二库存流水记录。

以上实施例二以及实施例三是与实施例一相对应的，仅是描述的角度有所不同，因此，相关的具体实现请参见实施例一中的介绍即可，这里不再赘述。

与实施例一相对应，本申请实施例还提供了一种库存数据对账装置，应用于对账服务器，参见图4，该装置可以包括：

第一账务信息接收单元401，用于通过预置的数据存储引擎接收平台方业务服务器回流的第一账务信息，所述第一账务信息包括根据平台方第一库存数据库的库存变化生成的第一库存流水记录，以及根据所述第一库存数据库在指定时刻的状态生成的第一库存快照；

第二账务信息提取单元402，用于从仓库方提供的仓库服务器中提取第二账务信息，所述第二账务信息包括根据仓库方第二库存数据库的库存变化生成的第二库存流水，以及根据所述第二库存数据库在所述指定时刻的状态生成的 第二库存快照；

第二账务信息处理单元403，用于对所述第二账务信息进行解析，并上传到所述数据存储引擎；

账务信息对比单元404，用于在所述数据存储引擎中，将指定对账周期内的第一账务信息以及第二账务信息进行对比，确定两者之间的差异信息；

差异信息提供单元405，用于提供所述差异信息。

其中，所述第二账务信息提取单元具体用于：

从仓库方提供的仓库服务器中提取第二账务信息到第一服务器的固定目录；

所述第二账务信息处理单元具体用于

利用第二服务器从所述第一服务器的固定目录复制所述第二账务信息，并进行分析，将分析结果上传到所述数据存储引擎。

具体实现时，所述差异信息提供单元包括：

差异类型确定子单元，用于确定各条差异信息的差异类型；

提供子单元，用于按照所述差异类型提供所述差异信息。

其中，库存流水记录中包括订单编号信息，其中，针对同一订单在第一库存数据库与第二库存数据库之间进行库存数据同步时，双方的库存流水记录中的订单编号信息相同；所述账务信息对比单元具体用于：

根据第一库存流水记录与第二库存流水记录中是否存在相同订单编号的记录，以及相同订单编号的记录中操作数量信息是否相同，确定两者之间的差异信息。

具体实现时，该装置还可以包括：

核查单元，用于所述确定出两者之间的差异信息之后，利用所述对账周期之前和/或之后预置时间段内的第一库存流水记录以及第二库存流水记录，对 所述对账周期内存在差异的部分进行核查；

确定单元，用于如果仍然存在差异，则确定为差异信息。

与实施例二相对应，本申请实施例还提供了一种库存数据对账装置，应用于平台方业务服务器，参见图5，该装置可以包括：

第一账务信息确定单元501，用于确定第一账务信息，所述第一账务信息包括根据平台方第一库存数据库的库存变化生成的第一库存流水记录，以及根据所述第一库存数据库在指定时刻的状态生成的第一库存快照；

第一账务信息回流单元502，用于将所述第一账务信息回流到预置的数据存储引擎，以便对账服务器在将仓库服务器提供的第二账务信息进行解析并上传到所述数据存储引擎后，在所述数据存储引擎中，将指定对账周期内的第一账务信息以及第二账务信息进行对比，确定两者之间的差异信息；

其中，所述第二账务信息包括根据仓库方第二库存数据库的库存变化生成的第二库存流水，以及根据所述第二库存数据库在所述指定时刻的状态生成的第二库存快照。

其中，所述回流到数据存储引擎的第一库存流水记录包括所述对账周期内的第一库存流水记录，以及对账周期之前和/或之后预置时间段内的第一库存流水记录。

与实施例三相对应，本申请实施例还提供了一种库存数据对账装置，应用于仓库服务器，参见图6，该装置可以包括：

第二账务信息确定单元601，用于确定第二账务信息，所述第二账务信息包括根据仓库方第二库存数据库的库存变化生成的第二库存流水，以及根据所述第二库存数据库在所述指定时刻的状态生成的第二库存快照；

对账周期确定单元602，用于根据对账服务器指定的时间确定对账周期；

账务文件生成单元603，用于根据所述对账周期，将所述第二库存流水以及所述第二库存快照生成账务文件，并保存到预置的仓库服务器，以便对账服务器从所述仓库服务器读取所述账务文件，进行解析后上传到预置的数据存储引擎，并在将平台方的第一账务信息回流到所述数据存储引擎后，在所述数据存储引擎中，将指定对账周期内的第一账务信息以及第二账务信息进行对比，确定两者之间的差异信息；

其中，所述第一账务信息包括根据平台方第一库存数据库的库存变化生成的第一库存流水，以及根据所述第一库存数据库在所述指定时刻的状态生成的第一库存快照。

其中，所述账务文件中的账务文件中包括对账周期内的第二库存流水记录，以及对账周期之前和/或之后预置时间段内的第二库存流水记录。

通过本申请实施例，平台方以及仓库方的数据都可以上传到对账服务器的数据存储引擎，并利用该数据存储引擎实现对平台方以及仓库方的库存数据进行对账，避免两者长时间存在差异不被发现而导致的超卖等现象。并且，由独立的对账服务器在数据存储引擎中执行对账操作，因此，可以避免对平台方具体业务的运行造成影响。

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

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也 可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本申请所提供的库存数据对账方法及装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。