提供业务对象配送时效信息的方法及装置与流程

本申请涉及业务对象信息处理技术领域，特别是涉及提供业务对象配送时效信息的方法及装置。

背景技术：

电子商务销售平台的买家在浏览业务对象时，通常会进入到业务对象的详情页，在详情页中去了解其可能感兴趣的内容，并根据详情页中展示的内容，决定是否需要购买。其中，在进行购买决策时，除了需要参考业务对象本身的描述信息、评论信息等之外，买家往往还需要了解关于配送方面的信息，例如，何时能够收到货品，等等。

但是，在浏览业务对象时，由于商家选择的物流服务商不同、发货地不同等因素，导致到货时效也有所不同，而且即使上一次购买了同样商品，是同一家快递公司进行派送，也可能这次送达的时效是不一样的。这种“抽奖式”的体验，让买家得不到很确切的承诺送货时间。在这种情况下，买家要么放弃购买，要么先下单，但是如果长时间未收到货品，则还可能申请取消订单，等等，对于买家用户而言，可能会浪费其时间成本，而对于系统而言，这种反复下单再取消等操作，会浪费大量的系统资源。

为了解决上述问题，有些销售平台可以在业务对象的详情页中提供配送时效信息，使得买家用户可以以此为参考，帮助进行购买决策。但是，现有技术中提供的配送时效信息往往不够准确，经常会出现无法在承诺的期限内送达的现象，影响用户体验。

技术实现要素：

本申请提供了提供业务对象配送时效信息的方法及装置，能够使得给出的配送时效信息更为准确。

本申请提供了如下方案：

一种提供业务对象配送时效信息的方法，包括：

服务器提供物流配送能力信息数据库，所述数据库用于包括至少一个物流服务提供方的配送能力信息，所述配送能力信息包括：从第一地点到第二地点是否支持在预置的时效内送达，以及在预置时间段内，按照所述时效进行配送时所能承载的最大数量；

接收浏览指定业务对象详情页的请求，并确定所述业务对象的发货地、收货地以及预先为所述业务对象选定的目标物流服务提供方标识；

根据所述数据库，确定所述目标物流服务提供方在所述发货地以及收货地之间是否支持在预置的时间期限内送达；

如果支持，则确定所述预置时间段内，该物流服务提供方已经在该发货地以及收货地之间承载的订单数量；

判断该数量是否小于所述最大数量，如果小于，则提供该业务对象的配送时效信息，所述配送时效信息用于表达：从当前时刻生成订单，则该业务对象对应的货品可在所述预置的时间期限内送达。

一种提供业务对象配送时效信息的方法，包括：

客户端接收浏览指定业务对象详情页的请求；

将所述请求转发至服务器，以便服务器确定所述业务对象的发货地、收货地以及预先为所述业务对象选定的目标物流服务提供方标识，根据预置的数据库，确定所述目标物流服务提供方在所述发货地以及收货地之间是否支持在预置的时间期限内送达，如果支持，则确定所述预置时间段内，该物流服务提供方已经在该发货地以及收货地之间承载的订单数量，并判断该订单数量是否小于该目标物流服务提供方能够承载的最大订单数量，如果小于，则生成该业务对象的配送时效信息并返回；

接收所述服务器返回的配送时效信息，并在所述详情页中提供所述配送时效信息。

一种提供业务对象配送时效信息的装置，应用于服务器，包括：

数据库提供单元，用于提供物流配送能力信息数据库，所述数据库用于包括至少一个物流服务提供方的配送能力信息，所述配送能力信息包括：从第一地点到第二地点是否支持在预置的时效内送达，以及在预置时间段内，按照所述时效进行配送时所能承载的最大数量；

信息确定单元，用于接收浏览指定业务对象详情页的请求，并确定所述业务对象的发货地、收货地以及预先为所述业务对象选定的目标物流服务提供方标识；

判断单元，用于根据所述数据库，确定所述目标物流服务提供方在所述发货地以及收货地之间是否支持在预置的时间期限内送达；

已承载数据确定单元，用于如果支持，则确定所述预置时间段内，该物流服务提供方已经在该发货地以及收货地之间承载的订单数量；

配送时效信息提供单元，用于判断该数量是否小于所述最大数量，如果小于，则提供该业务对象的配送时效信息，所述配送时效信息用于表达：从当前时刻生成订单，则该业务对象对应的货品可在所述预置的时间期限内送达。

一种提供业务对象配送时效信息的装置，应用于客户端，包括：

请求接收单元，用于接收浏览指定业务对象详情页的请求；

请求转发单元，用于将所述请求转发至服务器，以便服务器确定所述业务对象的发货地、收货地以及预先为所述业务对象选定的目标物流服务提供方标识，根据预置的数据库，确定所述目标物流服务提供方在所述发货地以及收货地之间是否支持在预置的时间期限内送达，如果支持，则确定所述预置时间段内，该物流服务提供方已经在该发货地以及收货地之间承载的订单数量，并判断该订单数量是否小于该目标物流服务提供方能够承载的最大订单数量，如果小于，则生成该业务对象的配送时效信息并返回；

时效信息接收单元，用于接收所述服务器返回的配送时效信息，并在所述详情页中提供所述配送时效信息。

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

通过本申请实施例，关于物流服务提供方的配送能力，除了考虑发货地与收货地的地点因素之外，还考虑了在一指定时间段内能够承载的最大配送数量这一因素，这样，可以使得给出的配送时效信息更为准确。

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

附图说明

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

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

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

图3是本申请实施例提供的用户界面的示意图；

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

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

具体实施方式

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

本申请发明人在实现本申请的过程中发现，现有技术中，销售平台在给出配送时效信息时，通常仅考虑发货地与收货地两者的地理位置因素，只要物流服务器提供方能够在两地之间实现在指定的时效内送达(例如，付款后24小时内等等，为便于描述，将这种服务称为“次日达”)，就在业务对象详情页中 给出关于配送时效的承诺信息。但是，在实际应用中，即使某物流服务提供方能够在某两个地点之间实现“次日达”等配送时效，但是，由于物流服务器提供方的人力物力等资源毕竟是有限的，因此，在一定时间段能够承载的配送数量也是有限的。也就是说，假设某物流服务提供方能够在北京与天津两地之间实现“次日达”，但是，该物流服务提供方一天可能只能承载1000单，超出该数量之后，该物流服务提供方也无法在北京与天津之间实现次日达了。此时，如果仍然向买家用户做出配送时效的承诺，则很可能会出现超出承诺期限的情况，影响用户的体验。

因此，在本申请实施例中，关于物流服务提供方的配送能力，除了需要考虑发货地与收货地的地点因素之外，还可以考虑在一指定时间段内能够承载的最大配送数量这一因素，从而使得给出的配送时效信息更为准确。下面对具体的实现方式进行介绍。

在具体实现时，首先可以提供一物流配送能力信息数据库，该数据库中可以保存至少一个物流服务提供方的配送能力信息，该配送能力信息可以包括两个方面的信息，一方面是：从第一地点到第二地点是否支持在预置的时效内送达，以及另一方面：在预置时间段内，按照该时效进行配送时所能承载的最大数量。例如，在一种具体实现方式下，该数据库中的具体内容可以如以下表1所示：

表1

以上数据库中的具体数据可以是由各个物流服务提供方提供的，也就是说，物流服务提供方可以根据自身的情况，确定是否提供“次日达”服务，如果能够提供，则可以提交相关的配送能力信息，由销售平台服务器进行保存。这样，后续在具体提供业务对象的配送时效信息时，就可以依据该配送能力信息数据库进行确定。

需要说明的是，在实际应用中，对于能够支持“次日达”的目的地，可以精确到区县级，这是因为，同一物流服务提供方针对同一城市的不同区县，提供“次日达”的能力可能会是不同的。例如，对于杭州市而言，某物流服务提供方可能能够在上城区做“次日达”，而余杭区则由于站点配送能力不足等原因，无法做到“次日达”，因此，在上述表1中，当以杭州市为目的地时，就可以精确到具体的区县，从而更精确地给出配送时效信息。

下面对具体的提供配送时效信息的过程进行介绍。

实施例一

参见图1，本申请实施例一从服务器的角度，提供了一种提供业务对象配送时效信息的方法，该方法可以包括以下步骤：

S101：服务器提供物流配送能力信息数据库，所述数据库用于包括至少一个物流服务提供方的配送能力信息，所述配送能力信息包括：从第一地点到第二地点是否支持在预置的时效内送达，以及在预置时间段内，按照所述时效进行配送时所能承载的最大数量；

关于该数据库的具体信息可以参见前文中的介绍。

S102：接收浏览指定业务对象详情页的请求，并确定所述业务对象的发货 地、收货地以及预先为所述业务对象选定的目标物流服务提供方标识；

当买家用户在浏览业务对象信息时，如果点击了该业务对象详情页链接，则服务器就可以接收到浏览该业务对象详情页的请求，此时，可以展示出关于该业务对象的具体描述信息等，此外，在本申请实施例中，还可以通过后续的判断操作，确定是否为该业务对象承诺出具体的配送时效信息。

为此，首先可以确定出该业务对象对应的发货地、收货地以及预先为所述业务对象选定的目标物流服务提供方标识。其中，关于发货地以及目标物流服务提供方，可以是预先由商家或者卖家配置的，并且可以预先写入详情页的网页文件中，这样，服务器在解析网页文件时，就可以确定出发货地以及目标物流服务提供方。另外，在实际应用中，商家可能会在多个仓库中都有关于同一业务对象的库存，关于发货地，可能会根据收货地动态确定，因此，可能会先确定出收货地，然后利用就近原则等确定出发货地。当然，具体的实现逻辑可以采用已有技术中的方式实现，本申请实施例中，只要提取出发货地的确定结果即可。

而关于收货地，则可以通过多种方式确定。例如，如果买家用户已经登录到销售平台，则可以根据销售平台服务器中记录中关于该买家用户的历史购买记录等信息，确定出该买家用户的常用收货地址信息，以该常用收货地址作为当前的收货地。或者，还可以确定出买家用户当前所在的地理位置，以该位置作为当前业务对象的收货地。具体的，在确定当前用户所在的地理位置时，也可以有多种方式，例如，其中一种方式可以是根据IP地址确定，或者，在另一种方式下，由于现有的终端设备通常具有定位功能，因此，可以通过定位的方式确定出当前买家用户所在的地理位置，等等。

需要说明的是，服务器能够区分出买家用户使用的终端设备的类型，因此，在买家用户使用移动终端设备浏览业务对象详情页的情况下，可以优先使用前述通过定位的方式来确定收货地址的方式。当然，在实际应用中，移动终端设备中的定位功能可能会被用户关闭，或者，没有为销售平台应用开放定位功能，则在这种情况下，可以不为该买家用户提供关于当前业务对象的配送时效信息。

S103：根据所述数据库，确定所述目标物流服务提供方在所述发货地以及收货地之间是否支持在预置的时间期限内送达；

在确定出发货地、收货地以及目标物流服务提供方后，可以查询前述数据库，确定出该目标物流服务提供方在所述发货地以及收货地之间是否支持在预置的时间期限内送达。例如，假设确定出的目标物流服务提供方是物流商甲，发货地是杭州，收货地是上海，则通过查询前述表1，可以获知该物流商甲在当前的发货地与收货地之间支持“次日达”。

另外，由于数据库中还保存有在提供“次日达”服务时能够承载的最大订单数量，因此，在确定出在当前的发货地与收货地之间支持“次日达”后，还可以确定出当前物流服务提供方在该发货地与收货地之间能够承载的最大订单数量，例如，为表1中所述的1000单，等等。

S104：如果支持，则确定所述预置时间段内，该物流服务提供方已经在该发货地以及收货地之间承载的订单数量；

在确定出目标物流提供方能够在当前的发货地与收货地之间支持“次日达”后，就可以确定出在某时间段内，该物流服务提供方已经在该发货地以及收货地之间承载的订单数量。其中，该时间段可以根据承诺的配送时效来确定，例如，仍然以“次日达”为例，配送时效为24小时，则来计算已承载的订单数量时，可以以一天为一个时间段，例如，从00：00到24：00，也就是说，以每天的00：00作为该时间段的起始时间点，开始对各个物流提供方分别在各发货地与收货地之间承载的订单数量进行计数，也即，每次接收到一个订单时，就可以将对应的目标物流服务提供方在对应发货地与收货地之间的已承载订单数量进行加一操作。这样，当接收到当前的浏览请求时，就可以判断出当前物流服务提供方从当天的00：00到当前时刻，已经承载了多少个承诺了“次日达”的订单。

S105：判断该数量是否小于所述最大数量，如果小于，则提供该业务对象的配送时效信息，所述配送时效信息用于表达：从当前时刻生成订单，则该业务对象对应的货品可在所述预置的时间期限内送达。

如果已承载的数量小于能够承载的最大数量，则可以在该业务对象的详情页中提供承诺的配送时效信息，例如，提供“次日达”字样，等等，这样，买家用户就可以通过该信息预估出货品的送达时间。当然，在提供该业务对象的配送时效信息时，还可以将该物流服务提供方已经在该发货地以及收货地之间承载的数量执行加一操作。

具体实现时，除了给出前述关于是否支持“次日达”的承诺之外，还可以计算出具体的到货时间，以进一步提高用户体验。具体的，可以根据当前时刻的时间点以及所述时效的时间长度，计算预计的送达时间。例如，可以以买家用户具体的付款时间作为参考值，则对于买家用户在0:00-16:00前付款的订单，则物流承诺的时间为次日24:00前；而对于买家用户在16:00-24:00付款的订单，物流承诺时间为可以第三天24:00前。

需要说明的是，虽然本申请实施例中提供配送时效时，已经考虑了发货地以及收货地的地点信息，还充分考虑了物流提供方能够承载的订单数量信息，但是，在具体实现时，可能仍然会有无法按时送达的情况。对于同一物流提供方而言，如果仅仅是个别几次的超时，可能并不能说明什么，但是，如果同一物流提供方经常性地出现超时现象，则可能说明该物流提供方的实际能力并不足以满足“次日达”的要求。此时，如果仍然按照前述方式提供配送时效信息，则买家用户可能会经常面临无法按时收到货品的现象，影响用户体验，也影响整个销售平台的服务质量。

为此，在本申请实施例中，还可以对物流服务提供方的实际送达情况进行统计，根据统计结果，对物流服务提供方的实际配送能力进行考核。具体的，可以以XX天为期对业务对象到从某发货地到某收货地的物流时效数据进行考核。考核方法可以为：以城市为单位统计“次日达”时效到达率，达标后，对应的业务对象可以继续获得前端表达，如果未达标，则可以在有效订购期内，继续考核。

关于考核结果是否达标，可以有多种方式，例如，对于在某天0：01-16：00间付款的订单，物流签收时间在次日24：00之前，在某天16：00-24：00间付款的订单，物流签收时间为第三天24：00前，如果符合这两个时间截点 内的订单便可以确定为合格的“次日达”订单，否则，为非合格次日达订单。

以30天为考核周期为例，以城市为单位，累计时效达标率大于或等于N％(该数值可以由运营配置，例如可以为85％，支持规则变更)即表示考核成功，次日达率公式可以为：收货地累计合格“次日达”订单数量/收货地累计全部订单数量。

关于考核周期的计算，可以是从订购之日起，后置XX天为考核期，订购成功时间为考核开始时间，往后加XX天为考核截止时间。例如，考核周期为30天时，某商家订购时间为2015/4/9 18：00，则考核截止时间为：2015/5/9 18：00。

或者，还可以采用月度考核的方式，此时，考核周期的计算方式可以为：每个月最后一天上午10：00为数据截止日期，截取从这一天开始往前取30天的累计时效达标率数据，等等。

实施例二

以上实施例一从服务器的角度对本申请实施例进行了介绍，而该实施例二则是从客户端的角度进行介绍。

参见图2，该实施例二提供了一种提供业务对象配送时效信息的方法，该方法可以包括以下步骤：

S201：客户端接收浏览指定业务对象详情页的请求；

S202：将所述请求转发至服务器，以便服务器确定所述业务对象的发货地、收货地以及预先为所述业务对象选定的目标物流服务提供方标识，根据预置的数据库，确定所述目标物流服务提供方在所述发货地以及收货地之间是否支持在预置的时间期限内送达，如果支持，则确定所述预置时间段内，该物流服务提供方已经在该发货地以及收货地之间承载的订单数量，并判断该订单数量是否小于该目标物流服务提供方能够承载的最大订单数量，如果小于，则生成该业务对象的配送时效信息并返回；

S203：接收所述服务器返回的配送时效信息，并在所述详情页中提供所述配送时效信息。

客户端具体在详情页中展示配送时效信息时，可以如图3所示，其中关于“次日达”的标识，以及关于“付款后承诺在后天(5月8日)24：00前送达”，即为关于配送时效信息的展示。

以上实施例二是与实施例一相对应的，具体的实现细节可以参见实施例一中的介绍，这里不再赘述。

与实施例一相对应，本申请实施例还提供了一种提供业务对象配送时效信息的装置，该装置应用于服务器，参见图4，该装置可以包括：

数据库提供单元401，用于提供物流配送能力信息数据库，所述数据库用于包括至少一个物流服务提供方的配送能力信息，所述配送能力信息包括：从第一地点到第二地点是否支持在预置的时效内送达，以及在预置时间段内，按照所述时效进行配送时所能承载的最大数量；

信息确定单元402，用于接收浏览指定业务对象详情页的请求，并确定所述业务对象的发货地、收货地以及预先为所述业务对象选定的目标物流服务提供方标识；

判断单元403，用于根据所述数据库，确定所述目标物流服务提供方在所述发货地以及收货地之间是否支持在预置的时间期限内送达；

已承载数据确定单元404，用于如果支持，则确定所述预置时间段内，该物流服务提供方已经在该发货地以及收货地之间承载的订单数量；

配送时效信息提供单元405，用于判断该数量是否小于所述最大数量，如果小于，则提供该业务对象的配送时效信息，所述配送时效信息用于表达：从当前时刻生成订单，则该业务对象对应的货品可在所述预置的时间期限内送达。

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

数量操作单元，用于在所述提供该业务对象的配送时效信息时，将该物流服务提供方已经在该发货地以及收货地之间承载的数量执行加一操作。

其中，所述配送时效信息提供单元包括：

送达时间计算子单元，用于根据当前时刻的时间点以及所述时效的时间长度，计算预计的送达时间；

送达时间提供子单元，用于提供所述预置的送达时间。

具体实现时，可以通过以下方式确定收货地：

第一收货地确定单元，用于根据当前用户的历史订单中的常用收货地址，确定收货地。

或者，通过以下方式确定收货地：

第二收货地确定单元，用于根据IP地址确定收货地。

或者，通过以下方式确定收货地：

第三收货地确定单元，用于根据终端设备的定位结果，确定收货地。

在实际应用中，该装置还可以包括：

考核单元，用于对同一物流服务方在预置考核周期内对同一收货地按照所述配送时效内完成配送的合格率进行考核；

触发单元，用于如果合格率符合预置条件，则触发所述提供该业务对象的配送时效信息的步骤。

与实施例二相对应，本申请实施例还提供了一种提供业务对象配送时效信息的装置，该装置应用于客户端，参见图5，该装置可以包括：

请求接收单元501，用于接收浏览指定业务对象详情页的请求；

请求转发单元502，用于将所述请求转发至服务器，以便服务器确定所述业务对象的发货地、收货地以及预先为所述业务对象选定的目标物流服务提供方标识，根据预置的数据库，确定所述目标物流服务提供方在所述发货地以及 收货地之间是否支持在预置的时间期限内送达，如果支持，则确定所述预置时间段内，该物流服务提供方已经在该发货地以及收货地之间承载的订单数量，并判断该订单数量是否小于该目标物流服务提供方能够承载的最大订单数量，如果小于，则生成该业务对象的配送时效信息并返回；

时效信息接收单元503，用于接收所述服务器返回的配送时效信息，并在所述详情页中提供所述配送时效信息。

总之，通过本申请实施例，关于物流服务提供方的配送能力，除了考虑发货地与收货地的地点因素之外，还考虑了在一指定时间段内能够承载的最大配送数量这一因素，这样，可以使得给出的配送时效信息更为准确。

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

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

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