文档中心 > 基础技术

天猫时效承诺场景

更新时间:2023/04/03 访问次数:65626

本次变更点:

承诺到货降级为预计到货时效,目前已经上线。需要商家ISV做相应的对接改造,没有做isv对接的商家无法感知预计到货时效,可能会影响商家发货。由于是预计到货时效,商家无赔付风险,如果商家发货和到货没到考核标准,预计到货时效也将不表达。

原有的承诺到货timing_promise:tmallPromise;promise_service:arrival.timing下线,改为预计到货时效timing_promise:tmallEstimate; promise_service:tmallestimate.arrival.timing。


一、场景介绍

1. 概述


天猫提供时效服务,通过服务平台化和商家赋能,为消费者提供并展示标准物流时效服务,提升消费者物流确定性体验。本次优先推进实现发货时效(如承诺当天发货、24h发货)和到货时效(承诺当日达、次日达等);


image.png


2. 价值


面向商家:1)实现已有服务能力的有效表达;2)供应链成本优化:全链路提效;3)物流能力提升:实现发货和配送能力提升;

面向消费者:1)提供时效的确定性;2)提供快速的配送效率;3)提供增值的优质物流服务  

时效承诺服务介绍:点击查看


二、技术方案整体说明


完整接入天猫时效承诺,ISV需要能支持仓库管理、商品/货品库存管理、以及天猫时效承诺订单的识别,并将相关信息透传到商家或者商家仓库。我们对商家(包含单仓和多仓商家,流程存在差异)提供了对接的简化流程,减轻商家的接入成本。

承诺到货降级为预计到货时效,目前已经上线。需要商家isv做相应的对接改造,没有做isv对接的商家无法感知预计到货时效,可能会影响商家发货。由于是预计到货时效,商家无赔付风险,如果商家发货和到货没到考核标准,预计到货时效也将不表达。

原有的承诺到货timing_promise:tmallPromise;promise_service:arrival.timing下线,改为预计到货时效timing_promise:tmallEstimate; promise_service:tmallestimate.arrival.timing。

?

1. 单仓模式商家


1)商家签约天猫时效承诺服务(发货/到货服务)

2)创建仓库:在商家中心后台/接口创建仓库(若单仓商家,则创建一个默认仓库即可)

3)设定库存模式:读取单仓仓库库存模式(单仓模式)&读取分仓库存模式(多仓模式)

4)维护库存:通过原有维护前端商品库存的接口进行库存维护(系统会自动读取,无需调用货品维护库存的接口),商品库存接口:skus.quantity.update,taobao.item.quantity.update,tmall.item.quantity.update;

5)订单履约&售后:获取天猫订单(订单上含时效服务信息)并履约,针对未达成&消费者投诉的订单,需进行赔付;


image.png


2. 多仓模式商家


1)商家签约天猫时效承诺服务(发货/到货服务)

2)创建仓库:在商家中心后台/接口创建仓库

3)设定库存模式:单仓仓库库存模式(单仓模式)&分仓库存模式(多仓模式)

4)维护库存:通过商品分仓库存接口/货品分仓库存的接口进行库存维护(taobao.inventory.merchant.adjust,该接口支持时效项目商家用商品维护库存,和原有商品库存编辑接口不同,具体说明可参见本文档库存维护部分)说明:商家可无需发布货品(系统默认将“商品id+skuid”为虚拟货品)、无需实现货品和商品的关联,直接维护商品分仓库存,具体可参见接口说明;

5)订单履约&售后:获取天猫订单(订单上含时效服务信息)并履约,针对未达成&消费者投诉的订单,需进行赔付;


image.png

 

在ISV需要进行改造的几点说明:

① 提供商家维护单多仓库存模式的入口(单多仓模式的维护,以商家在天猫后台维护的信息为准;可能存在商家就一个仓库,但是设置为分仓库存模式;需按照商家在天猫设置的单多仓库存模式,调用不同库存维护接口);

商品/货品分仓库存维护接口对接(主要提供给多仓商家,单仓商家可不接入);

③ 订单拆单后对商家的影响评估(商家ERP已有拆单逻辑的改造,如财务审核、货票同行等,需确认是否有问题);

④ 订单接口的时效服务字段识别。

 

三、对接接口说明

1. 仓库管理相关接口


不论是单仓商家还是多仓商家,商家需在天猫系统中创建维护自己的仓库基础资料;仓库相关的操作支持天猫商家中心后台直接操作(支持商家的仓库创建、仓库信息更新、覆盖范围设置的操作),也支持商家调用接口进行仓库管理;以下为对应的仓库接口;

1)仓库基础资料管理接口。可以在卖家中心后台管理商品仓库,也可以通过接口管理:taobao.inventory.store.manage 创建仓库;taobao.inventory.store.query 查询仓库;taobao.inventory.store.manage 修改仓库基础信息。

注意:系统创建时仓库编码全网唯一,不允许重复,或者商家维护错误等原因(创建后不允许更改),可能出现商家在ERP中仓库编码和在天猫商家后台维护的编码不一致的场景;为避免因为仓库编码不一致导致订单无法正常履约,则需要ISV系统支持 ISV系统中商家仓库编码 和 商家在天猫商家后台维护的仓库编码 映射的逻辑,确保订单生成后,ISV系统可以有效识别到订单的仓库信息,正常履约。

2)维护仓库覆盖范围(指仓库中商品可销售的范围,不同仓库的覆盖范围可交叉),暂时只提供页面功能,暂不开放接口;页面功能路径:商家中心->天猫时效服务->仓库管理->销售区域。


2. 库存管理接口

1) 商品库存维护接口(单仓模式商家)


针对单仓商家,支持通过原有维护前端商品库存的接口进行库存维护(系统会自动读取库存,无需调用货品维护库存的接口),商品库存接口:taobao.skus.quantity.update,taobao.item.quantity.update,tmall.item.quantity.update;


2) 货品库存维护接口(多仓模式商家) 


接口名称:货品库存商家端调整接口,taobao.inventory.merchant.adjust。

核心:支持多仓商家仅传入“商品id+skuid”维护库存,也支持商家单独创建货品后传入货品id维护库存(原有功能);

① 若商品是前端商品分仓库存模式,在维护商品的分仓库存时,则在sc_item_id 字段传入前端商品id,在sku_id字段传入sku的id,在store_code传入仓库code,即可维护对应skuid的对应仓库存;(若传入的商品id 已关联货品,那么系统不会更新库存到货品分仓库存上,需传入货品id维护库存);

② 若商品是后端货品分仓库存模式,在维护货品的分仓库存时,则在sc_item_id 字段传入后端货品id,在store_code传入仓库code,即可维护对应货品的对应仓库存(此时传入商品id,则更新库存失败);

③ 若商品没有关联货品同时商品也不是商品分仓库存模式,那么在该接口传入商品id时,则更新库存失败(此时直接使用原有前端商品库存接口更新库存);

注意:多仓模式的商家,在签署协议&维护库存模式后,第一次编辑商品库存的时候 需要以全量的方式更新库存(如商品a第一次编辑指定sku库存的时候,建议全量编辑,其他商品也一样;天猫的系统在此时有逻辑切换,若以增量的方式更新库存,系统默认从0开始增加);

 

3. 交易订单接口(核心接口)


订单接口新增了哪些逻辑:核心加入了时效信息(如时效服务的类型、最晚揽收时间、签收时间等)、仓库信息等;

1)接口名称taobao.trade.fullinfo.get

以下为完整字段说明,表格后两列为发货和到货时效订单所包含的字段(“是”表示商家需识别);


接口对应字段 发货时效订单 到货时效订单 描述
timing_promise

服务身份标识,

tmallEstimate

代表天猫预计时效-新增字段

promise_service

承诺服务类型,会有多个服务值,以英文半角逗号","切割,其中 

tmallestimate.arrival.timing代表预计到货时效-新增字段

tmallpromise.consign.timing代表发货承诺时效

es_date 预计送达时间,到天,格式2019-04-12
es_range 预计配送时间段,格式,09:00-21:00
os_date 预约配送时间,到天,格式2019-04-12 承诺预约配送的时间,非预约配送商家不存在该字段
os_range 预约配送时间段,格式,09:00-21:00 承诺预约配送的时间,非预约配送商家不存在该字段
cutoff_minutes 截单时间,表示该订单的截单时间(从商家维护截单时间引用),分钟级别,如660代表11:00
es_time 相对到达时间,单位为天,0当日达,1次日达,2三日达,3四日达,4五日达
delivery_time 最晚发货时间,日期,格式2019-04-12 16:00:00 时间等同于最晚揽收时间;
collect_time 最晚揽收时间,日期,格式2019-04-12 16:00:00 因发货以有物流揽收记录为准,因此发货和到货订单都会基于该字段进行发货的判责
dispatch_time 最晚派送时间,日期,格式2019-04-12 16:00:00 主要用于指导商家合理的派送时间,本期暂时不用;
sign_time 最晚签收时间,日期,格式2019-04-12 16:00:00 到货订单会依据该字段进行到货的判责
store_code 发货的仓库编码,如QDHEWL-0004,即商家在商家中心后台维护的仓库code 注意,该字段由IPM打上,只存在于交易子单上,并非本次项目新增,属于一直存在的字段


 2)通过RDS推送获取订单。则需在RDS后台勾选 timing_promise和promise_service字段,然后在trade-attr即可获取对应的时效信息(务必在包含timing_promise和promise_service字段的订单中查看该信息,否则即使trade-attr中有对应时效字段,但该订单非时效承诺订单),具体RDS字段勾选页面:


image.png


下图为RDS推送后在trade-attr中可获取的信息:


image.png


4. FAQ


1)这些字段是主(父)订单维度的,还是子订单维度的?

主订单和子订单相同,届时会在主子订单上都打上,主子保持一致;注意,针对storeCode,即发货仓字段,只存在于子订单上,主订单没有。


2)发货时效订单的判责依据?

按照实际揽收时间和订单上记录的最晚揽收时间进行对比,若实际揽收时间晚于最晚揽收时间,则说明订单发货履约时效未达成,消费者投诉需赔付。


3)到货时效订单的判责依据?

按照实际签收时间和订单上记录的最晚签收时间进行对比,若实际签收时间晚于最晚=签收时间,则说明订单到货履约时效未达成,消费者投诉需赔付。


4)timing_promise 的意义。

timing_promise 只是标识商家开通了时效承诺服务; 如果订单不满足时效, promise_service 就为空,以及相关的时效时间参数都没有; 如果有满足时效,promise_service就有参数,相应时效时间参数会返回。


5)是否可以通过taobao.trades.sold.get接口获取时效信息。

Sold .get接口定位为订单状态的查询,订单详情的获取都使用trade.fullinfo.get接口(包括时效信息),也避免因为sold.get接口的数据延迟给业务带来影响。


6)trade-attr的示例。

"trade_attr":"{\"esDate\":\"2019-06-05\",\"erpHold\":\"0\",\"tmallDelivery\":\"true\",\"esRange\":\"00:00-23:59\",\"cnService\":\"82\"}"


7)返回值示例。

{ "trade_fullinfo_get_response":{ "request_id":"107acwais7msf", "trade":{ "timing_promise":"tmallPromise", "new_presell":false, "promise_service":"tmallpromise.arrival.timing", "you_xiang":false, "es_time":"2" } } }


四、 isv内部系统改造的其他要求


为了保障商家操作体验,isv系统需要提供基础功能:

1)支持天猫时效承诺订单的筛选(区分各个类型,当日发货、24h发货、当日达、次日达、隔日达、四日达、五日达);

2)订单页面展示,对应订单的时效信息透出

3)天猫时效承诺订单合单换仓等操作的提示(合单/换仓后可能导致时效无法履约,造成赔付);

isv在拉取订单基础上,除了以上基础功能外,可以自行考虑增加其他功能。


image.png



FAQ

关于此文档暂时还没有FAQ
返回
顶部