为物流运输请求生成承载单的信息处理方法和装置与流程

本申请涉及信息处理领域，尤其涉及一种为物流运输请求生成承载单的信息处理方法和装置。

背景技术：

在现有的物流体系中，通常由供货方、仓配一体方(物流网，如日日顺物流)通过网络协同合作来完成物品的仓储和配送。该物流体系的结构图如图1所示。由一个或多个供货方1～n将物品统一运输至物流网在全国分散布置的多个仓储实体，例如日日顺物流在全国分布的5个一级仓和22个二级仓。供货方可以将物品运输到一级仓，然后通过一级仓再运输到二级仓，也可以直接将物品运输到二级仓。然后，由物流网统一为一个或多个供货方1～n提供物品的仓储服务和将物品配送至一个或多个用户1～n的服务。

目前这种模式比较适合线下有自己的仓库(或生产基地)并且自己的仓库靠近全国分散布置的多个仓储实体的供货方，以便于近距离地将物品从商家的仓库运输到多个仓储实体。而对于其他商家，比如线下虽然有自己的仓库，但是自己的仓库距离上述多个仓储实体较远或者没有将物品从自己的仓库运输到上述多个仓储实体的较便捷的物流资源的商家，如果这些商家销货量相对较少，每次都需要远距离或极其不便利地将少量货运输到上述多个仓储实体，显然会导致单次发货的物流成本较高。为了解决单次少量发货的成本问题，现有的改进方案主要采用延长发货周期来提高商家每次从物源地发货到仓储实体的发货量。但是，延长发货周期依然会产生其他问题，比如无法灵活应对前端销售的变化。

技术实现要素：

本申请的目的之一是解决供货方在货量较少的情况下仍然需要远距离地或不便利地占用一次运输资源来将货运输到物流网的仓储实体的问题，提高物流运转的效率。

根据本申请的一个实施例，提供了一种为物流运输请求生成承载单的信息处理方法，该方法包括：

第一服务器接收来自不同用户设备的、携带同一时间信息的、用于将不同用户存放在同一集货仓的物品运输到物流网的仓储实体的多个物流运输请求；

获取与所携带的时间信息对应的运输资源信息；

如果所述多个物流运输请求和所述运输资源信息满足预定规则，针对所述多个物流运输请求生成合承载单。

根据本申请的一个实施例，提供了一种过滤物流运输请求的信息处理方法，其中所述物流运输请求是将物品从集货仓运输到物流网的仓储实体的请求，该方法包括：

第二服务器基于待过滤物流运输请求的运输负荷量，确定所述运输负荷量需要的集货仓配置、运输资源配置、仓储实体配置；

获取实际的集货仓配置、运输资源配置、仓储实体配置；

基于所述运输负荷量需要的集货仓配置、运输资源配置、仓储实体配置、以及获取的实际的集货仓配置、运输资源配置、仓储实体配置，对待过滤物流运输请求进行过滤；

将过滤后的物流运输请求发给第一服务器，以便第一服务器在接收到多个过滤后的物流运输请求、且该多个过滤后的物流运输请求和过滤后的物流运输请求中的时间信息对应的运输资源信息满足预定规则的条件下，针对所述多个过滤后的物流运输请求生成合承载单。

根据本申请的一个实施例，提供了一种对承载单与出库单进行关联的信息处理方法，该方法包括：

第三服务器响应于接收到物流运输请求，生成对应的用于物品出库的出库单；

响应于接收到合承载单，将所述合承载单与所述合承载单涉及的物 流运输请求对应的出库单进行关联，以便对所述出库单上的物品进行合承载，其中合承载单是在带有同一时间信息的多个用于将不同用户存放在同一集货仓的物品运输到物流网的仓储实体的物流运输请求和与该时间信息对应的运输资源信息满足预定规则的情况下针对所述多个物流运输请求生成的。

根据本申请的一个实施例，提供了一种对承载单与入库单进行关联的信息处理方法，该方法包括：

第四服务器响应于接收到物流运输请求，生成对应的用于物品入库的入库单；

响应于接收到合承载单，将所述合承载单与所述合承载单涉及的物流运输请求对应的入库单进行关联，以便对合承载的物品进行入库，其中合承载单是在带有同一时间信息的多个用于将不同用户存放在同一集货仓的物品运输到物流网的仓储实体的物流运输请求和与该时间信息对应的运输资源信息满足预定规则的情况下针对所述多个物流运输请求生成的。

根据本申请的一个实施例，提供了一种设置合承载规则的信息处理方法，该方法包括：

第五服务器展示物流运输请求中包含的要素和运输资源信息中包含的要素；

响应于接收到对物流运输请求中包含的要素和运输资源信息中包含的要素的关联操作，生成合承载规则；

将所述合承载规则发送给第一服务器，以便第一服务器在带有同一时间信息的多个用于将不同用户存放在同一集货仓的物品运输到物流网的仓储实体的物流运输请求和与该时间信息对应的运输资源信息满足合承载规则的情况下针对所述多个物流运输请求生成合承载单。

根据本申请的一个实施例，提供了一种为物流运输请求生成承载单的信息处理装置，该装置包括：

接收单元，用于接收来自不同用户设备的、携带同一时间信息的、用于将不同用户存放在同一集货仓的物品运输到物流网的仓储实体的多 个物流运输请求；

运输资源信息获取单元，用于获取与所携带的时间信息对应的运输资源信息；

合承载单生成单元，用于如果所述多个物流运输请求和所述运输资源信息满足预定规则，针对所述多个物流运输请求生成合承载单。

根据本申请的一个实施例，提供了一种过滤物流运输请求的信息处理装置，其中所述物流运输请求是将物品从集货仓运输到物流网的仓储实体的请求，该装置包括：

确定单元，用于基于待过滤物流运输请求的运输负荷量，确定所述运输负荷量需要的集货仓配置、运输资源配置、仓储实体配置；

配置获取单元，用于获取实际的集货仓配置、运输资源配置、仓储实体配置；

过滤单元，用于基于所述运输负荷量需要的集货仓配置、运输资源配置、仓储实体配置、以及获取的实际的集货仓配置、运输资源配置、仓储实体配置，对待过滤物流运输请求进行过滤；

过滤后物流运输请求发送单元，用于将过滤后的物流运输请求发给第一服务器，以便第一服务器在接收到多个过滤后的物流运输请求、且该多个过滤后的物流运输请求和过滤后的物流运输请求中的时间信息对应的运输资源信息满足预定规则的条件下，针对所述多个过滤后的物流运输请求生成合承载单。

根据本申请的一个实施例，提供了一种对承载单与出库单进行关联的信息处理装置，该装置包括：

出库单生成单元，用于响应于接收到物流运输请求，生成对应的用于物品出库的出库单；

合承载单与出库单关联单元，用于响应于接收到合承载单，将所述合承载单与所述合承载单涉及的物流运输请求对应的出库单进行关联，以便对所述出库单上的物品进行合承载，其中合承载单是在带有同一时间信息的多个用于将不同用户存放在同一集货仓的物品运输到物流网的仓储实体的物流运输请求和与该时间信息对应的运输资源信息满足预定 规则的情况下针对所述多个物流运输请求生成的。

根据本申请的一个实施例，提供了一种对承载单与入库单进行关联的信息处理装置，该装置包括：

入库单生成单元，用于响应于接收到物流运输请求，生成对应的用于物品入库的入库单；

合承载单与入库单关联单元，用于响应于接收到合承载单，将所述合承载单与所述合承载单涉及的物流运输请求对应的入库单进行关联，以便对合承载的物品进行入库，其中合承载单是在带有同一时间信息的多个用于将不同用户存放在同一集货仓的物品运输到物流网的仓储实体的物流运输请求和与该时间信息对应的运输资源信息满足预定规则的情况下针对所述多个物流运输请求生成的。

根据本申请的一个实施例，提供了一种设置合承载规则的信息处理装置，该装置包括：

展示单元，用于展示物流运输请求中包含的要素和运输资源信息中包含的要素；

合承载规则生成单元，用于响应于接收到对物流运输请求中包含的要素和运输资源信息中包含的要素的关联操作，生成合承载规则；

合承载规则发送单元，用于将所述合承载规则发送给第一服务器，以便第一服务器在带有同一时间信息的多个用于将不同用户存放在同一集货仓的物品运输到物流网的仓储实体的物流运输请求和与该时间信息对应的运输资源信息满足合承载规则的情况下针对所述多个物流运输请求生成合承载单。

由于在本申请的一个实施例中，设置集货仓，在用户的物品发送到物流网的仓储实体之前在集货仓暂存，这样如果接收到来自不同用户设备(供货方终端)的、将其在同一集货仓暂存的物品在同一时间发送到物流网的仓储实体的多个物流运输请求，获取该时间的运输资源信息，如果所述多个物流运输请求和所述运输资源信息满足预定规则，针对所述多个物流运输请求生成合承载单，这样，就可以用同一运输资源(例如一辆车)为多个用户同时运输物品到物流网的仓储实体，从而解决了 如果用户需要运输的物品太少仍然占用整个一个运输资源导致效率太低的问题，提高了物流运转的效率。

本领域普通技术人员将了解，虽然下面的详细说明将参考图示实施例以及附图进行，但本申请并不仅限于这些实施例。而是，本申请的范围是广泛的，且意在仅通过后附的权利要求限定本申请的范围。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：

图1是现有技术中的物流体系框架图。

图2是本申请的一个实施例所应用的物流体系框架图。

图3是本申请的一个实施例中所涉及的各执行主体的控制关系图。

图4是根据本申请的一个实施例在第一服务器侧的为物流运输请求生成承载单的信息处理方法的流程图。

图5是根据本申请的一个实施例在第二服务器侧的过滤物流运输请求的信息处理方法的流程图。

图6是根据本申请的一个实施例在第三服务器侧的对承载单与出库单进行关联的信息处理方法的流程图。

图7是根据本申请的一个实施例在第四服务器侧的对承载单与入库单进行关联的信息处理方法的流程图。

图8是根据本申请的一个实施例在第五服务器侧的设置合承载规则的信息处理方法的流程图。

图9是根据本申请的一个实施例在第一服务器侧的为物流运输请求生成承载单的信息处理装置的框图。

图10是根据本申请的一个实施例在第二服务器侧的过滤物流运输请求的信息处理装置的框图。

图11是根据本申请的一个实施例在第三服务器侧的对承载单与出库单进行关联的信息处理装置的框图。

图12是根据本申请的一个实施例在第四服务器侧的对承载单与入库 单进行关联的信息处理装置的框图。

图13是根据本申请的一个实施例在第五服务器侧的设置合承载规则的信息处理装置的框图。

附图中相同或相似的附图标记代表相同或相似的部件。

具体实施方式

下面结合附图对本申请作进一步详细描述。

在更加详细地讨论示例性实施例之前应当提到的是，一些示例性实施例被描述成作为流程图描绘的处理或方法。虽然流程图将各项操作描述成顺序的处理，但是其中的许多操作可以被并行地、并发地或者同时实施。此外，各项操作的顺序可以被重新安排。当其操作完成时所述处理可以被终止，但是还可以具有未包括在附图中的附加步骤。所述处理可以对应于方法、函数、规程、子例程、子程序等等。

在上下文中所称“计算机设备”，也称为“电脑”，是指可以通过运行预定程序或指令来执行数值计算和/或逻辑计算等预定处理过程的智能电子设备，其可以包括处理器与存储器，由处理器执行在存储器中预存的存续指令来执行预定处理过程，或是由ASIC、FPGA、DSP等硬件执行预定处理过程，或是由上述二者组合来实现。计算机设备包括但不限于服务器、个人电脑、笔记本电脑、平板电脑、智能手机等。

所述计算机设备包括用户设备与网络设备。其中，所述用户设备包括但不限于电脑、智能手机、PDA等；所述网络设备包括但不限于单个网络服务器、多个网络服务器组成的服务器组或基于云计算(Cloud Computing)的由大量计算机或网络服务器构成的云，其中，云计算是分布式计算的一种，由一群松散耦合的计算机集组成的一个超级虚拟计算机。其中，所述计算机设备可单独运行来实现本申请，也可接入网络并通过与网络中的其他计算机设备的交互操作来实现本申请。其中，所述计算机设备所处的网络包括但不限于互联网、广域网、城域网、局域网、VPN网络等。

需要说明的是，所述用户设备、网络设备和网络等仅为举例，其他 现有的或今后可能出现的计算机设备或网络如可适用于本申请，也应包含在本申请保护范围以内，并以引用方式包含于此。

后面所讨论的方法(其中一些通过流程图示出)可以通过硬件、软件、固件、中间件、微代码、硬件描述语言或者其任意组合来实施。当用软件、固件、中间件或微代码来实施时，用以实施必要任务的程序代码或代码段可以被存储在机器或计算机可读介质(比如存储介质)中。(一个或多个)处理器可以实施必要的任务。

这里所公开的具体结构和功能细节仅仅是代表性的，并且是用于描述本申请的示例性实施例的目的。但是本申请可以通过许多替换形式来具体实现，并且不应当被解释成仅仅受限于这里所阐述的实施例。

这里所使用的术语仅仅是为了描述具体实施例而不意图限制示例性实施例。除非上下文明确地另有所指，否则这里所使用的单数形式“一个”、“一项”还意图包括复数。还应当理解的是，这里所使用的术语“包括”和/或“包含”规定所陈述的特征、整数、步骤、操作、单元和/或组件的存在，而不排除存在或添加一个或更多其他特征、整数、步骤、操作、单元、组件和/或其组合。

还应当提到的是，在一些替换实现方式中，所提到的功能/动作可以按照不同于附图中标示的顺序发生。举例来说，取决于所涉及的功能/动作，相继示出的两幅图实际上可以基本上同时执行或者有时可以按照相反的顺序来执行。

在描述本申请实施例的信息处理方法和装置之前，为了更好地理解该信息处理方法和装置，先对本申请实施例所应用的体系框架进行介绍。

如图2所示，相比于图1中现有技术的物流体系框架，本申请实施例在物联网前端设置集货仓，供货方要发送的物品在实际发送到物流网的仓储实体(例如，一级仓，二级仓)之前在集货仓暂存。例如，可以将一个城市划分成若干地理区域，一个地理区域有一个集货仓。在这个地理区域中的所有供货方将其物品暂存在该集货仓，当需要把这些物品发送到物流网的仓储实体时就从集货仓发送，而不是从供货方自己的仓库发送。集货仓相当于供货方自己的仓库的外延，但是集货仓被整个地 理区域的所有供货方所共有。这样，按照本申请的一个实施例，当位于同一地理区域的多个供货方需要在同一时间将自己暂存在集货仓的物品发送到物流网的仓储实体时，如果这多个供货方中的每个供货方其实都只有少量的物品需要发送占用一个运输资源(例如，一辆车)非常可惜的话，就有可能合在一起占用一个运输资源运输，从而提供物流运转效率。

本申请实施例主要针对物品从集货仓到供货方需要发到的物联网仓储实体(例如，一级仓或二级仓)的运输中的信息处理方法和装置。从集货仓到供货方需要发到的物流网仓储实体(例如，一级仓或二级仓)的运输由干线完成。干线指负责集货仓和物流网仓储实体之间的物流运输(包括从集货仓到仓储实体的正向运输和从仓储实体到集货仓的逆向运输)的实体。在物流平台，干线、仓储实体、集货仓可能由不同的部门负责，每个部门相对独立，有自己的子管理平台和服务器。如图3所示，有负责干线运输的管理和控制的第一服务器12、负责对集货仓的物品存储的管理和控制的第三服务器13、负责对仓储实体的仓储的管理和控制的第四服务器14。另外，还有负责与用户(供货方)接口、接收用户的物流运输请求从而向负责集货仓的第三服务器13、负责干线运输的第一服务器12、负责仓储实体的第四服务器进行协调，以保障满足用户的物流运输请求的物流宝平台(前端平台，供货方与物流网的接口)的第二服务器。第二服务器11、第三服务器13、第一服务器12、第四服务器14在协作运行以完成物品的承运的过程中涉及到各种规则和参数，各服务器根据这些规则和参数进行各种调度。小二平台上的第五服务器15负责对这些规则和参数进行配置，以辅助整个体系构架的运行。

图4是根据本申请的一个实施例在第一服务器(例如干线服务器)侧的为物流运输请求生成承载单的信息处理方法的流程图。该方法包括：

S101、第一服务器接收来自不同用户设备的、携带同一时间信息的、用于将不同用户存放在同一集货仓的物品运输到物流网的仓储实体的多个物流运输请求；

S102、获取与所携带的时间信息对应的运输资源信息；

S103、如果所述多个物流运输请求和所述运输资源信息满足预定规则，针对所述多个物流运输请求生成合承载单。

下面对这些步骤进行详细描述。

在步骤S101中，第一服务器接收来自不同用户设备的、携带同一时间信息的、用于将不同用户存放在同一集货仓的物品运输到物流网的仓储实体的多个物流运输请求。

这里的用户设备是指供货方的终端。这里的时间信息是指物流运输请求携带的、要求将物品从集货仓向物流网的仓储实体进行运输的起始时间。

例如，用户1希望在2015年7月23日将其存储在集货仓A中的物品B发送到物流网中的某二级仓C，用户2希望在2015年7月23日将其存储在集货仓A中的物品D发送到物流网中的某一级仓E。这时，第一服务器就接收到来自用户1的用户设备的、在2015年7月23日将其存储在集货仓A中的物品B发送到物流网中的二级仓C的物流运输请求，以及来自用户2的用户设备的、在2015年7月23日将其存储在集货仓A中的物品D发送到物流网中的一级仓E的物流运输请求。由于都是在2015年7月23日开始运输，其携带的时间信息相同，且都是从集货仓A开始运输，虽然运输到的具体的实体仓库可能不同，但物流网的各级存储实体是一个整体，只要到达了物流网中的某一仓储实体，物品在物流网内部流转是十分效率和快捷的。因此，在用户1和用户2各自希望运输的物品B和物品D很少时，有可能将用户1和用户2希望运输的物品用同一运输资源(例如一辆车)运输到物流网中的某一仓储实体(例如，距离集货仓A比较近的仓储实体)，然后物品在物流网中内部流转，直至分别到达二级仓C和一级仓E。

物流运输请求中除了包括发出请求的用户(供货方)、其要运输的物品名、该物品所在的集货仓、该物品要运输到的仓储实体，还包括例如请求运输的物品的总体积、总重量、总件数等等，在有多个干线可服务的情况下，也可以包括希望承担运输的干线，等等。

在步骤S102中，获取与所携带的时间信息对应的运输资源信息。

运输资源指干线中可以用来运输的运输工具，例如各种型号的车、船、飞机等。这些运输资源并不是每分每秒都可以获得的。例如，当某辆车在某一天已经被之前的物流运输请求预订，在该天用来满足该之前的物流运输请求，则在该天该车就是不可获得的。运输资源信息包括这些可以用来运输的运输工具的容积、最大载重量、运输禁忌等。

与所携带的时间信息对应的运输资源信息是指在该时间信息指示的时间可获得的运输资源的信息，例如它们的容积、最大载重量、运输禁忌等。例如，在2015年7月23日可获得的运输工具只有货车F，则与所携带的时间信息中的时间2015年7月23日对应的运输资源信息是货车F的容积、最大载重量、运输禁忌等。

获取与所携带的时间信息对应的运输资源信息可以通过查询数据库的方式进行，其中该数据库将时间信息与可获得的运输资源信息相对应地存储。如果在某时间信息指示的时间，某一运输资源被预订满足某一物流运输请求，则从数据库中将该时间信息对应的运输资源的运输资源信息删除。

S103、如果所述多个物流运输请求和所述运输资源信息满足预定规则，针对所述多个物流运输请求生成合承载单。

承载单的种类有装车单、装船单、装机单等。它是在特定运输资源(运输工具)上所承载的物品的单据。在该运输资源(运输工具)达到目的地后，按照该承载单清点该运输资源上的物品是否短缺。在本申请实施例中，它不必服务于一个用户设备的一个物流运输请求。在本申请实施例中，在一个运输资源上可能承载有不同用户暂存在同一集货仓的不同物品。这样，当几个用户其实都只有少量的物品需要发送时，有可能将它们的物品合在一起占用一个运输资源运输，从而提供物流运转效率。合承载单就是用一个运输资源同时满足多个物流运输请求的承载单。

在一个实施例中，在所述运输资源信息包括运输资源的容积、所述物流运输请求包括请求运输的物品的总体积、且每个物流运输请求中的总体积都小于运输资源的容积的情况下，步骤S103包括：如果所述多个 物流运输请求中的总体积之和小于或等于运输资源的容积，生成用同一运输资源承载所述多个物流运输请求的物品的合承载单。

例如，第一物流运输请求是来自用户1的用户设备的、希望在2015年7月23日将其存储在集货仓A中的20立方米的物品B发送到物流网中的二级仓C的物流运输请求。第二物流运输请求是来自用户2的用户设备的、在2015年7月23日将其存储在集货仓A中的9立方米物品D发送到物流网中的一级仓E的物流运输请求。在2015年7月23日只有货车F。货车F的容积是30立方米。由于第一物流运输请求中的物品总体积20立方米、第二物流运输请求中的物品总体积9立方米之和小于货车F的容积30立方米，生成用货车F承载20立方米的物品B和9立方米的物品D的合承载单。

在另一个实施例中，在所述运输资源信息包括运输资源的最大载重量、所述物流运输请求包括请求运输的物品的总重量、且每个物流运输请求中的总重量都小于运输资源的最大载重量的情况下，步骤S103包括：如果所述多个物流运输请求中的总重量之和小于或等于运输资源的最大载重量，生成用同一运输资源承载所述多个物流运输请求的物品的合承载单。

例如，第一物流运输请求是来自用户1的用户设备的、希望在2015年7月23日将其存储在集货仓A中的7吨的物品B发送到物流网中的二级仓C的物流运输请求。第二物流运输请求是来自用户2的用户设备的、在2015年7月23日将其存储在集货仓A中的2吨物品D发送到物流网中的一级仓E的物流运输请求。在2015年7月23日只有货车F。货车F的最大载重量是10吨。由于第一物流运输请求中的物品总重量7吨、第二物流运输请求中的物品总重量2吨之和小于货车F的最大载重量10吨，生成用货车F承载7吨的物品B和2吨的物品D的合承载单。

在另一个实施例中，在所述运输资源信息包括运输资源的容积、所述物流运输请求包括请求运输的物品的总体积、且至少一个物流运输请求中的总体积大于运输资源的容积的情况下，步骤S103包括：分别将所述至少一个物流运输请求中的总体积减去运输资源容积的整数倍，直到 剩下的体积小于运输资源容积；如果所述至少一个物流运输请求的所述剩下的体积与所述多个物流运输请求中的其余物流运输请求中的总体积之和小于或等于运输资源的容积，生成用同一运输资源承载所述至少一个物流运输请求的所述剩下的体积的物品以及所述其余物流运输请求的物品的合承载单。

例如，第一物流运输请求是来自用户1的用户设备的、希望在2015年7月23日将其存储在集货仓A中的68立方米的物品B发送到物流网中的二级仓C的物流运输请求。第二物流运输请求是来自用户2的用户设备的、在2015年7月23日将其存储在集货仓A中的9立方米物品D发送到物流网中的一级仓E的物流运输请求。在2015年7月23日只有货车F。货车F的容积是30立方米。而第一物流运输请求中物品B的总体积68立方米就远大于货车F的容积30立方米。这时，将第一物流运输请求中物品B的总体积68立方米减去货车F的容积的2倍，使第一物流运输请求剩下的体积8立方米小于货车F的容积。也就是说，对于第一物流运输请求中物品B的总体积68立方米，先用两辆货车F分别运输30立方米(一般来说，物流运输请求中的物品都是散件可拆的，如家电、日用品，对于大的雕像等一件就超过一辆货车的容积的情况不在本实施例讨论范围内)。对于剩下的8立方米，其与第二物流运输请求中物品D的总体积9立方米之和17立方米小于货车F的容积30立方米，因此可以对于剩下的8立方米物品B与第二物流运输请求中9立方米物品D合起来用一辆货车F运输，即生成用货车F承载第一物流运输请求中剩下的8立方米物品B与第二物流运输请求中9立方米物品D的合承载单。

这一实施例的好处是，由于多个用户暂存在同一集货仓的物品都非常少、又需要在同一天发往物流网的仓储实体的情况并不是一种普遍的情况，更普遍的情况是，确实有多个用户要将暂存在同一集货仓的物品在同一天发往物流网的仓储实体，但这多个用户未必每个用户需要发送的物品都非常少，这时，如何对这多个用户需要运输的物品进行更有效率的物流组织，使物流运输成本最小，是一个更普遍的问题。通过该实施例的先拆后合，即先将总体积超出运输资源容积的物流运输请求中的 总体积分出若干个运输资源容积，再考虑是否可以将剩余的小于运输资源容积的部分与其余物流运输请求中的物品用同一个运输资源运走，更普遍意义地提高了物流的效率。

类似地，在另一个实施例中，在所述运输资源信息包括运输资源的最大载重量、所述物流运输请求包括请求运输的物品的总重量、且至少一个物流运输请求中的总重量大于运输资源的最大载重量的情况下，步骤S103包括：分别将所述至少一个物流运输请求中的总重量减去所述最大载重量的整数倍，直到剩下的重量小于所述最大载重量；如果所述至少一个物流运输请求的所述剩下的重量与所述多个物流运输请求中的其余物流运输请求中的总重量之和小于或等于运输资源的最大载重量，生成用同一运输资源承载所述至少一个物流运输请求的所述剩下的重量的物品以及所述其余物流运输请求的物品的合承载单。

例如，第一物流运输请求是来自用户1的用户设备的、希望在2015年7月23日将其存储在集货仓A中的27吨的物品B发送到物流网中的二级仓C的物流运输请求。第二物流运输请求是来自用户2的用户设备的、在2015年7月23日将其存储在集货仓A中的2立方米物品D发送到物流网中的一级仓E的物流运输请求。在2015年7月23日只有货车F。货车F的最大载重量是10吨。而第一物流运输请求中物品B的总重量27吨就远大于货车F的最大载重量10吨。这时，将第一物流运输请求中物品B的总重量27吨减去货车F的最大载重量的2倍，使第一物流运输请求剩下的重量7吨小于货车F的最大载重量。也就是说，对于第一物流运输请求中物品B的总重量27吨，先用两辆货车F分别运输10吨(在物流运输请求中的物品都是散件可拆的前提下)。对于剩下的7吨，其与第二物流运输请求中物品D的总重量2吨之和9吨小于货车F的最大载重量10吨，因此可以对于剩下的7吨物品B与第二物流运输请求中2吨物品D合起来用一辆货车F运输，即生成用货车F承载第一物流运输请求中剩下的7吨物品B与第二物流运输请求中2吨物品D的合承载单。

图5示出了根据本申请的一个实施例在第二服务器(物流宝平台服 务器)侧的一种过滤物流运输请求的信息处理方法的流程图。所述物流运输请求是将物品从集货仓运输到物流网的仓储实体的请求。物流宝平台是在供货方与物联网之间接口的一个平台。供货方通过其终端登录到物流宝平台上用于生成物流运输请求的网页，将其打算从集货仓运到物流网的仓储实体的物品名称、数量、时间、体积、吨数、集货仓名、要运到的仓储实体名等输入该网页，从而生成物流运输请求。在本实施例中，它只是一个待过滤的物流运输请求，物流宝平台服务器需要将它过滤后发送到第三服务器(集货仓服务器)、第一服务器(干线服务器)、第四服务器(仓储实体服务器)。在图4中的步骤S101中第一服务器接收到的物流运输请求实际上是过滤后的物流运输请求。

这种过滤的好处是：在没有本申请的过滤机制之前，用户的物流运输请求直接发送给集货仓服务器用于出库、发送给干线服务器用于干线运输、发送给存储实体服务器用于入库，但一旦集货仓、干线、仓储实体中有一方能力不足，例如仓储实体方面最近没有收货人员等，导致整个物流中断、中止，降低物流效率。本实施例通过这种过滤机制，有效避免了对于集货仓、干线、仓储实体有一方能力不足时物流资源的浪费和低效。

如图5所示，该方法包括：S201、第二服务器基于待过滤物流运输请求的运输负荷量，确定所述运输负荷量需要的集货仓配置、运输资源配置、仓储实体配置；S202、获取实际的集货仓配置、运输资源配置、仓储实体配置；S203、基于所述运输负荷量需要的集货仓配置、运输资源配置、仓储实体配置、以及获取的实际的集货仓配置、运输资源配置、仓储实体配置，对待过滤物流运输请求进行过滤；S204、将过滤后的物流运输请求发给第一服务器，以便第一服务器在接收到多个过滤后的物流运输请求、且该多个过滤后的物流运输请求和过滤后的物流运输请求中的时间信息对应的运输资源信息满足预定规则的条件下，针对所述多个过滤后的物流运输请求生成合承载单。

下面分别对这些步骤进行进一步的详细描述。

在步骤S201中，第二服务器基于待过滤物流运输请求的运输负荷量， 确定所述运输负荷量需要的集货仓配置、运输资源配置、仓储实体配置。

运输负荷量是指待过滤运输请求中的物品的总体积或总重量等。

所述集货仓配置是指集货仓在分拣物品出库时的能力配置，具体可以包括：分拣物品出库的人员数量、各人员的拣货速度等。

所述运输资源配置是指运输工具的运输能力配置，具体可以包括：运输工具的类型、数量、各运输工具的容积、最大载重量等。

所述仓储实体配置是指仓储实体在物品入库时的收货人员的数量、各收货人员的速度等。

在一个实施例中，步骤S201包括：查找预置的运输负荷量与需要的集货仓配置、运输资源配置、仓储实体配置的对应关系表，以确定所述运输负荷量需要的集货仓配置、运输资源配置、仓储实体配置。

也就是说，事先将各种运输负荷量对应的需要的集货仓配置、运输资源配置、仓储实体配置仓储在一个对应关系表中。查找该表，就可以确定所述运输负荷量需要的集货仓配置、运输资源配置、仓储实体配置。

例如，待过滤物流运输请求中的物品的总重量是20吨。查找对应关系表，发现与20吨对应的集货仓配置为：发货人员4名、发货人员的拣货平均速度为20kg/分钟；20吨对应的运输资源配置为：2辆最大载重量为10吨的车辆；20吨对应的仓储实体配置为：收货人员4名、收货人员的收货平均速度为20kg/分钟。

在步骤S202中，获取实际的集货仓配置、运输资源配置、仓储实体配置。

在一个实施例中，步骤S202包括：向待过滤物流运输请求中的作为起点的集货仓的第三服务器获取在待过滤物流运输请求中的预计运输时间的实际的集货仓配置；向第一服务器获取在待过滤物流运输请求中的预计运输时间的实际的运输资源配置；向待过滤物流运输请求中的作为终点的仓储实体的第四服务器获取在待过滤物流运输请求中的预计运输时间的实际的仓储实体配置。

在集货仓的第三服务器存储有各时间与实际的集货仓配置的对应关系表，例如每天的集货仓配置。第三服务器通过查找该表，就能获得在 待过滤物流运输请求中的预计运输时间的实际的集货仓配置。在干线的第一服务器也存储有各时间与实际的运输资源配置的对应关系表，例如每天的运输资源配置。第一服务器通过查找该表，就能获得在待过滤物流运输请求中的预计运输时间的实际的运输资源配置。在仓储实体的第四服务器存储有各时间与实际的仓储实体配置的对应关系表，例如每天的仓储实体配置。第四服务器通过查找该表，就能获得在待过滤物流运输请求中的预计运输时间的实际的仓储实体配置。

例如，在上面待过滤物流运输请求中的物品的总重量是20吨的例子中，上面的待过滤物流运输请求中预计运输时间是2015年7月23日，则按上述方式获得的2015年7月23日实际的集货仓配置为：发货人员5名、发货人员的拣货平均速度为20kg/分钟；实际的运输资源配置为：10辆最大载重量为10吨的车辆；实际的仓储实体配置为：收货人员10名、收货人员的收货平均速度为30kg/分钟。

在步骤S203中基于所述运输负荷量需要的集货仓配置、运输资源配置、仓储实体配置、以及获取的实际的集货仓配置、运输资源配置、仓储实体配置，对待过滤物流运输请求进行过滤。

在一个实施例中，步骤S203包括：在获取的实际的集货仓配置低于所述运输负荷量需要的集货仓配置，或者获取的实际的运输资源配置低于所述运输负荷量需要的运输资源配置，或者获取的实际的仓储实体配置低于所述运输负荷量需要的仓储实体配置的情况下，将所述待过滤物流运输请求滤除。

在上述例子中，由于获得的2015年7月23日实际的集货仓发货人员数量5大于20吨所需要的集货仓发货人员数量4，实际的集货仓发货人员拣货的平均速度20kg/分钟等于20吨所需要的集货仓发货人员拣货的平均速度20kg/分钟，实际的运输资源数量10大于20吨所需要的运输资源数量2，实际的每个运输资源的最大载重量10吨等于20吨所需要的每个运输资源的最大载重量10吨，实际的仓储实体收货人员数量10大于20吨所需要的仓储实体收货人员数量4，实际的仓储实体收货人员的收货平均速度30kg/分钟大于20吨所需要的收货人员的收货平均速度 20kg/分钟，因此不将所述待过滤物流运输请求滤除。

在步骤S204中，将过滤后的物流运输请求发给第一服务器，以便第一服务器在接收到多个过滤后的物流运输请求、且该多个过滤后的物流运输请求和过滤后的物流运输请求中的时间信息对应的运输资源信息满足预定规则的条件下，针对所述多个过滤后的物流运输请求生成合承载单。

第一服务器在接收到多个过滤后的物流运输请求、且该多个过滤后的物流运输请求和过滤后的物流运输请求中的时间信息对应的运输资源信息满足预定规则的条件下，针对所述多个过滤后的物流运输请求生成合承载单的过程在结合图4的描述中已经说明，故不赘述。

在本实施例中，不是将用户的物流运输请求直接发送给第三服务器(集货仓服务器)用于出库、发送给第一服务器(干线服务器)用于干线运输、发送给第四服务器(存储实体服务器)用于入库，而是考量实际的集货仓配置能否达到该物流运输请求需要的集货仓配置的要求、实际的运输资源配置能否达到该物流运输请求需要的运输资源配置的要求、实际的仓储实体配置能否达到该物流运输请求需要的仓储实体配置的要求，一旦有一方面达不到要求，就将用户的物流运输请求滤除，从而避免一旦集货仓、干线、仓储实体中有一方能力不足导致整个物流中断、中止，降低物流效率的问题，提高了物流资源的利用率和物流效率。

图6示出了根据本申请的一个实施例的在第三服务器(例如集货仓服务器)侧的一种对承载单与出库单进行关联的信息处理方法。出库单是表明未来需要出库的物品及数量的单据。当生成出库单时，物品可能还未出库。在接收到第一服务器(干线服务器)发送的承载单时，物品实际出库。在接收到承载单时，将生成的出库单与承载单关联，从而确认要运输的是哪些出库单上的哪些物品，以达到对集货仓库存的完善管理。

如图6所示，该方法包括：S301、第三服务器响应于接收到物流运输请求，生成对应的用于物品出库的出库单；S302、响应于接收到合承 载单，将所述合承载单与所述合承载单涉及的物流运输请求对应的出库单进行关联，以便对所述出库单上的物品进行合承载，其中合承载单是在带有同一时间信息的多个用于将不同用户存放在同一集货仓的物品运输到物流网的仓储实体的物流运输请求和与该时间信息对应的运输资源信息满足预定规则的情况下针对所述多个物流运输请求生成的。

下面对这些步骤分别进行详细的描述。

在步骤S301中，第三服务器响应于接收到物流运输请求，生成对应的用于物品出库的出库单。

由于物流运输请求包括例如打算从集货仓运到物流网的仓储实体的物品名称、数量、时间、体积、吨数、集货仓名、要运到的仓储实体名等，相应的出库单也包含这些信息。但是，生成出库单时物品并不实际出库。

在步骤S302中，响应于接收到合承载单，将所述合承载单与所述合承载单涉及的物流运输请求对应的出库单进行关联，以便对所述出库单上的物品进行合承载，其中合承载单是在带有同一时间信息的多个用于将不同用户存放在同一集货仓的物品运输到物流网的仓储实体的物流运输请求和与该时间信息对应的运输资源信息满足预定规则的情况下针对所述多个物流运输请求生成的。

上述合承载单的生成过程在上面结合图4的描述中已经说明，故不赘述。

由于合承载单涉及多个物流运输请求中的物品的承载，而一个物流运输请求对应于一张出库单，因此一张合承载单可能与多张出库单进行关联。由于结合图4的实施例的描述中所述，可能会将一些物流运输请求中的物品拆开后一部分与其它物流运输请求中的物品或一部分物品合在一起用一个运输资源运输，因此，一张合承载单可能只涉及某一张出库单中的部分物品或某些出库单中的部分物品。关联的含义就是针对一张合承载单，确定它涉及哪些出库单上的哪些物品。

在一个实施例中，步骤S302具体包括：识别合承载单上物流运输请求的编号及相应物品、物品的数量和/或体积和/或重量；根据合承载单上 物流运输请求的编号查找带有该物流运输请求的编号的出库单；从查找到的出库单中将所述数量和/或体积和/或重量的物品标记为出库。

例如，一张合承载单记录有第一物流运输请求的编号YD10003、第二物流运输请求的编号YD10004。在合承载单上，YD10003下有8立方米的物品B，YD10004下有9立方米的物品D。查找到带有第一物流运输请求的编号YD10003的出库单CT80007，发现其上共有68立方米的物品B。查找到带有第二物流运输请求的编号YD10004的出库单CT80328，发现其上有9立方米的物品D。因此，将出库单CT80007上的8立方米的物品B标记为出库，该出库单可能仍剩下60立方米的物品B未出库。将出库单CT80328上的9立方米的物品D全部标记为出库。

该实施例通过承载单与出库单的关联，达到的好处是，在合承载单包括多个物流运输请求的物品的情况下，能够判断出它涉及哪些出库单中的哪些物品的出库，便于对集货仓的物品的管理，提高物流管理效率。

图7示出了根据本申请的一个实施例的在第四服务器(例如存储实体服务器)侧的一种对承载单与入库单进行关联的信息处理方法。入库单是表明未来需要入库的物品及数量的单据。当生成入库单时，物品可能还未入库。在接收到第一服务器(干线服务器)发送的承载单时，物品实际入库。在接收到承载单时，将生成的入库单与承载单关联，从而确认运输到的是哪些出库单上的哪些物品，以达到对存储实体库存的完善管理。

如图7所示，该方法包括：S401、第四服务器响应于接收到物流运输请求，生成对应的用于物品入库的入库单；S402、响应于接收到合承载单，将所述合承载单与所述合承载单涉及的物流运输请求对应的入库单进行关联，以便对合承载的物品进行入库，其中合承载单是在带有同一时间信息的多个用于将不同用户存放在同一集货仓的物品运输到物流网的仓储实体的物流运输请求和与该时间信息对应的运输资源信息满足预定规则的情况下针对所述多个物流运输请求生成的。

下面对这些步骤分别进行详细的描述。

在步骤S401中，第四服务器响应于接收到物流运输请求，生成对应的用于物品入库的入库单。

由于物流运输请求包括例如打算从集货仓运到物流网的仓储实体的物品名称、数量、时间、体积、吨数、集货仓名、要运到的仓储实体名等，相应的入库单也包含这些信息。但是，生成入库单时物品并不实际入库。

在步骤S402中，响应于接收到合承载单，将所述合承载单与所述合承载单涉及的物流运输请求对应的入库单进行关联，以便对合承载的物品进行入库，其中合承载单是在带有同一时间信息的多个用于将不同用户存放在同一集货仓的物品运输到物流网的仓储实体的物流运输请求和与该时间信息对应的运输资源信息满足预定规则的情况下针对所述多个物流运输请求生成的。

上述合承载单的生成过程在上面结合图4的描述中已经说明，故不赘述。

由于合承载单涉及多个物流运输请求中的物品的承载，而一个物流运输请求对应于一张入库单，因此一张合承载单可能与多张入库单进行关联。由于结合图4的实施例的描述中所述，可能会将一些物流运输请求中的物品拆开后一部分与其它物流运输请求中的物品或一部分物品合在一起用一个运输资源运输，因此，一张合承载单可能只涉及某一张入库单中的部分物品或某些入库单中的部分物品。关联的含义就是针对一张合承载单，确定它涉及哪些入库单上的哪些物品。

在一个实施例中，步骤S302具体包括：识别合承载单上物流运输请求的编号及相应物品、物品的数量和/或体积和/或重量；根据合承载单上物流运输请求的编号查找带有该物流运输请求的编号的入库单；从查找到的入库单中将所述数量和/或体积和/或重量的物品标记为入库。

例如，一张合承载单记录有第一物流运输请求的编号YD10003、第二物流运输请求的编号YD10004。在合承载单上，YD10003下有8立方米的物品B，YD10004下有9立方米的物品D。查找到带有第一物流运输请求的编号YD10003的入库单FT30004，发现其上共有68立方米的物 品B。查找到带有第二物流运输请求的编号YD10004的入库单FT30005，发现其上有9立方米的物品D。因此，将出库单FT30004上的8立方米的物品B标记为入库，该入库单可能仍剩下60立方米的物品B未入库。将入库单FT30005上的9立方米的物品D全部标记为入库。

该实施例通过承载单与入库单的关联，达到的好处是，在合承载单包括多个物流运输请求的物品的情况下，能够判断出它涉及哪些入库单中的哪些物品的入库，便于对存储实体的物品的管理，提高物流管理效率。

图8示出了根据本申请的一个实施例在第三服务器(小二平台服务器)侧的一种设置合承载规则的信息处理方法。合承载规则即结合图4的实施例步骤S103中的预订规则，它是要生成合承载单所述多个物流运输请求和所述运输资源信息必须满足的规则。

如图8所示，该方法包括：S501、第五服务器展示物流运输请求中包含的要素和运输资源信息中包含的要素；S502、响应于接收到对物流运输请求中包含的要素和运输资源信息中包含的要素的关联操作，生成合承载规则；S503、将所述合承载规则发送给第一服务器，以便第一服务器在带有同一时间信息的多个用于将不同用户存放在同一集货仓的物品运输到物流网的仓储实体的物流运输请求和与该时间信息对应的运输资源信息满足合承载规则的情况下针对所述多个物流运输请求生成合承载单。

下面对这些步骤进行详细的描述。

在步骤S501中，第五服务器展示物流运输请求中包含的要素和运输资源信息中包含的要素。

物流运输请求中包含的要素包括物流运输请求中物品的总体积、总重量等。运输资源信息中包含的要素包括运输资源的容积、最大载重量等。

S502、响应于接收到对物流运输请求中包含的要素和运输资源信息中包含的要素的关联操作，生成合承载规则。

在一个实施例中，关联操作包括：将物流运输请求中的某一要素和运输资源信息中的某一要素拖动到某一区域，并将关联符号拖动到这两个要素之间。关联符号例如表示“和小于”、“和等于”、“和大于”、“和小于等于”等关联关系的符号。

例如，将展示的物流运输请求中的“总体积”要素、展示的运输资源信息中的“容积”要素拖动到屏幕的某一专门区域，再将屏幕上表示“和小于等于”的关联符号拖动到两个要素之间，生成的合承载规则为：如果所述多个物流运输请求中的总体积之和小于或等于运输资源的容积，生成用同一运输资源承载所述多个物流运输请求的物品的合承载单。

在步骤S503中，将所述合承载规则发送给第一服务器，以便第一服务器在带有同一时间信息的多个用于将不同用户存放在同一集货仓的物品运输到物流网的仓储实体的物流运输请求和与该时间信息对应的运输资源信息满足合承载规则的情况下针对所述多个物流运输请求生成合承载单。

第一服务器在带有同一时间信息的多个用于将不同用户存放在同一集货仓的物品运输到物流网的仓储实体的物流运输请求和与该时间信息对应的运输资源信息满足合承载规则的情况下针对所述多个物流运输请求生成合承载单的过程在上面结合图4的描述中已说明，故不赘述。

该实施例的好处是，小二平台管理人员通过选择展示的物流运输请求中的要素、运输资源信息中的要素，并选择关联符号关联操作，可以灵活生成合承载规则，提高了物流管理的灵活性。

图9示出了根据本申请一个实施例的一种为物流运输请求生成承载单的信息处理装置1的框图。该装置1包括：

接收单元101，用于接收来自不同用户设备的、携带同一时间信息的、用于将不同用户存放在同一集货仓的物品运输到物流网的仓储实体的多个物流运输请求；

运输资源信息获取单元102，用于获取与所携带的时间信息对应的运输资源信息；

合承载单生成单元103，用于如果所述多个物流运输请求和所述运输资源信息满足预定规则，针对所述多个物流运输请求生成合承载单。

可选地，所述运输资源信息包括运输资源的容积；所述物流运输请求包括请求运输的物品的总体积，其中每个物流运输请求中的总体积都小于运输资源的容积；所述合承载单生成单元用于：如果所述多个物流运输请求中的总体积之和小于或等于运输资源的容积，生成用同一运输资源承载所述多个物流运输请求的物品的合承载单。

可选地，所述运输资源信息包括运输资源的最大载重量；所述物流运输请求包括请求运输的物品的总重量，其中每个物流运输请求中的总重量都小于运输资源的最大载重量；所述合承载单生成单元用于：如果所述多个物流运输请求中的总重量之和小于或等于运输资源的最大载重量，生成用同一运输资源承载所述多个物流运输请求的物品的合承载单。

可选地，所述运输资源信息包括运输资源的容积；所述物流运输请求包括请求运输的物品的总体积，其中至少一个物流运输请求中的总体积大于运输资源的容积；所述合承载单生成单元用于：分别将所述至少一个物流运输请求中的总体积减去运输资源容积的整数倍，直到剩下的体积小于运输资源容积；如果所述至少一个物流运输请求的所述剩下的体积与所述多个物流运输请求中的其余物流运输请求中的总体积之和小于或等于运输资源的容积，生成用同一运输资源承载所述至少一个物流运输请求的所述剩下的体积的物品以及所述其余物流运输请求的物品的合承载单。

可选地，所述运输资源信息包括运输资源的最大载重量；所述物流运输请求包括请求运输的物品的总重量，其中至少一个物流运输请求中的总重量大于运输资源的最大载重量；所述合承载单生成单元用于：分别将所述至少一个物流运输请求中的总重量减去所述最大载重量的整数倍，直到剩下的重量小于所述最大载重量；如果所述至少一个物流运输请求的所述剩下的重量与所述多个物流运输请求中的其余物流运输请求中的总重量之和小于或等于运输资源的最大载重量，生成用同一运输资源承载所述至少一个物流运输请求的所述剩下的重量的物品以及所述其 余物流运输请求的物品的合承载单。

图10示出了根据本申请一个实施例的一种过滤物流运输请求的信息处理装置2的框图。所述物流运输请求是将物品从集货仓运输到物流网的仓储实体的请求。该装置2包括：

确定单元201，用于基于待过滤物流运输请求的运输负荷量，确定所述运输负荷量需要的集货仓配置、运输资源配置、仓储实体配置；

配置获取单元202，用于获取实际的集货仓配置、运输资源配置、仓储实体配置；

过滤单元203，用于基于所述运输负荷量需要的集货仓配置、运输资源配置、仓储实体配置、以及获取的实际的集货仓配置、运输资源配置、仓储实体配置，对待过滤物流运输请求进行过滤；

过滤后物流运输请求发送单元204，用于将过滤后的物流运输请求发给第一服务器，以便第一服务器在接收到多个过滤后的物流运输请求、且该多个过滤后的物流运输请求和过滤后的物流运输请求中的时间信息对应的运输资源信息满足预定规则的条件下，针对所述多个过滤后的物流运输请求生成合承载单。

可选地，所述确定单元用于：查找预置的运输负荷量与需要的集货仓配置、运输资源配置、仓储实体配置的对应关系表，以确定所述运输负荷量需要的集货仓配置、运输资源配置、仓储实体配置。

可选地，所述配置获取单元用于：

向待过滤物流运输请求中的作为起点的集货仓的第三服务器获取实际的集货仓配置；

向第一服务器获取实际的运输资源配置；

向待过滤物流运输请求中的作为终点的仓储实体的第四服务器获取实际的仓储实体配置。

可选地，所述过滤装置用于：在获取的实际的集货仓配置低于所述运输负荷量需要的集货仓配置，或者获取的实际的运输资源配置低于所述运输负荷量需要的运输资源配置，或者获取的实际的仓储实体配置低 于所述运输负荷量需要的仓储实体配置的情况下，将所述待过滤物流运输请求滤除。

图11示出了根据本申请的一个实施例的一种对承载单与出库单进行关联的信息处理装置3的框图。该装置3包括：

出库单生成单元301，用于响应于接收到物流运输请求，生成对应的用于物品出库的出库单；

合承载单与出库单关联单元302，用于响应于接收到合承载单，将所述合承载单与所述合承载单涉及的物流运输请求对应的出库单进行关联，以便对所述出库单上的物品进行合承载，其中合承载单是在带有同一时间信息的多个用于将不同用户存放在同一集货仓的物品运输到物流网的仓储实体的物流运输请求和与该时间信息对应的运输资源信息满足预定规则的情况下针对所述多个物流运输请求生成的。

图12示出了根据本申请的一个实施例的一种对承载单与入库单进行关联的信息处理装置4的框图。该装置4包括：

入库单生成单元401，用于响应于接收到物流运输请求，生成对应的用于物品入库的入库单；

合承载单与入库单关联单元402，用于响应于接收到合承载单，将所述合承载单与所述合承载单涉及的物流运输请求对应的入库单进行关联，以便对合承载的物品进行入库，其中合承载单是在带有同一时间信息的多个用于将不同用户存放在同一集货仓的物品运输到物流网的仓储实体的物流运输请求和与该时间信息对应的运输资源信息满足预定规则的情况下针对所述多个物流运输请求生成的。

图13示出了根据本申请的一个实施例的一种设置合承载规则的信息处理装置5的框图。该装置5包括：

展示单元501，用于展示物流运输请求中包含的要素和运输资源信息中包含的要素；

合承载规则生成单元502，用于响应于接收到对物流运输请求中包含的要素和运输资源信息中包含的要素的关联操作，生成合承载规则；

合承载规则发送单元503，用于将所述合承载规则发送给第一服务器，以便第一服务器在带有同一时间信息的多个用于将不同用户存放在同一集货仓的物品运输到物流网的仓储实体的物流运输请求和与该时间信息对应的运输资源信息满足合承载规则的情况下针对所述多个物流运输请求生成合承载单。

应当理解，附图中所示的系统的结构框图仅仅是为了示例的目的，而不是对本申请范围的限制。在某些情况下，可以根据具体情况增加或减少某些单元或模块。

所属技术领域的技术人员知道，本申请可以实现为系统、方法或计算机程序产品。因此，本公开可以具体实现为以下形式，即：可以是完全的硬件，也可以是完全的软件，还可以是硬件和软件结合的形式。

附图中的流程图和框图显示了根据本申请的多个实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

对于本领域技术人员而言，显然本申请不限于上述示范性实施例的细节，而且在不背离本申请的精神或基本特征的情况下，能够以其他的具体形式实现本申请。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本申请的范围由所附权利要求而不是上 述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。