淘宝开放平台

登录
文档中心 > 商家经营工具-开发指引

商家经营工具-开发指引

天猫时效承诺场景

更新时间：2024/07/31 访问次数：74206

本次变更点：

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

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


一、场景介绍

1. 概述


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



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）订单履约&售后：获取天猫订单（订单上含时效服务信息）并履约，针对未达成&消费者投诉的订单，需进行赔付；



2. 多仓模式商家


1）商家签约天猫时效承诺服务（发货／到货服务）

2）创建仓库：在商家中心后台／接口创建仓库

3）设定库存模式：单仓仓库库存模式（单仓模式）&分仓库存模式（多仓模式）

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

5）订单履约&售后：获取天猫订单（订单上含时效服务信息）并履约，针对未达成&消费者投诉的订单，需进行赔付；


?

在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字段勾选页面：



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



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在拉取订单基础上，除了以上基础功能外，可以自行考虑增加其他功能。




FAQ

关于此文档暂时还没有FAQ
有用(0) 我要提问
返回
顶部