基础技术
一、背景
近期淘宝新增了送礼场景的订单类型，存在付款人和收货人两个角色，在订单付款时尚未明确收件人信息，需要由收货人填写收货地址。主要涉及两个方面的的改造：收货人openld和收货人的淘宝昵称（模糊化）、预付邮费模式。
二、收货人openld和收货人的淘宝昵称（模糊化）
基于上述场景淘宝开放平台同步升级了此类业务场景下的交易模型，在部分交易相关数据查询接口上增加了【收货人openId】和【收货人的淘宝昵称】（模糊化），生态侧系统需要完成相应的适配，可参考下文中的改造方案。
1. 涉及的API列表
请服务商确认产品中以下接口的使用
这里的API接口包括正向和逆向
类型 |
接口 |
正向交易 |
taobao.trade.fullinfo.get taobao.trades.sold.get taobao.trades.sold.increment.get taobao.trades.sold.incrementv.get taobao.trade.simple.get taobao.trade.get taobao.trades.simple.sold.get taobao.trades.simple.sold.increment.get taobao.trades.sold.history.get taobao.open.trades.sold.get taobao.open.trade.get taobao.trades.sold.get.vo taobao.trade.fullinfo.get.vo taobao.trade.fullinfo.get.customization |
逆向退款 |
taobao.refund.get tmall.dispute.receive.get taobao.refunds.receive.get taobao.special.refund.get tmall.exchange.get tmall.exchange.receive.get taobao.special.refunds.receive.get |
2. 数据模型和能力变更
API接口侧主订单和退款单模型会增加如下的字段信息：
字段 |
描述 |
类型 |
real_receiver_open_id |
收件人淘宝加密openId |
string |
real_receiver_display_nick |
收件人淘宝加密昵称 |
string |
数据推送交易、退款、天猫换货的同步字段配置会增加real_receiver_open_id和real_receiver_display_nick（默认选中，不用单独配置）；相应的数据通过大字段的形式写入到jdp_response中。对应的表分别为：
sys_info库表 |
类型 |
jdp_tb_trade |
订单 |
jdp_tb_refund |
退款 |
jdp_exchange_refund |
天猫换货 |
开放平台消息
消息字段没有变更，不会增加数据，但对于单据信息上有收件人real_receiver_open_id的一些垂直场景的订单，创建和支付等消息不会下发。
字段识别和业务处理逻辑
1. 当real_receiver_open_id为空时，说明是普通场景的淘宝单据，按照普通的交易模式处理即可。
2. 当real_receiver_open_id不为空时，说明当前单据为本次业务模型相关的订单数据，需要在包括但不限于订单功能页、旺旺亮灯等页面做信息表达。
3. 字段解释：订单和退款单上的 buyer_open_uid 和buyer_nick表示付款人的信息；real_receiver_display_nick和real_receiver_open_id表示的是收货人的信息。
4. 旺旺亮灯：当前旺旺昵称唤起聊天展示时，需要新增对收货人信息：real_receiver_open_id和real_receiver_display_nick的识别展示。
3. 产品优化建议
产品类型 |
优化建议 |
参考效果 |
客服面板产品 |
1. 官方新增飘条提示：告知商家（客服人员）当前订单和进线咨询的消费者之间的关系（三方无需处理） —————————————————————— 2. 客服面板中【三方需要重点提示】的部分： a. 提示 1：无法识别到订单的场景如下，请使用公告提示，文案可参考：由于存在付款人和收货人不一致的送礼订单类型，在收货人确认收货地址前，暂时无法获取相关订单，如有问题请前往千牛后台-订单管理处理 i. 【付款人进线+不能识别订单】，由于收货人确认收货地址前，三方无法感知订单存在，此时订单列表无订单 ii.【收货人进线+不能识别订单】，由于三方未将收货人关联的订单进行合并，此时订单列表无订单 b. 提示 2：需要提醒客服人员严禁将付款人和收货人信息告知对方，依据进线消费者角色的差异，提示文案有所不同 i. 【付款人进线+能识别订单】，提示文案：当前订单为送礼订单，聊天对象为付款人，但非收货人。为保障用户信息及隐私，在聊天过程中请勿对其擅自透露订单的收货地址、物流轨迹等信息 ii. 【收货人进线+能识别订单】，提示文案：当前订单为送礼订单，聊天对象为收货人，但非付款人。为保障用户信息及隐私，在聊天过程中请勿对其擅自透露订单的支付账号、优惠权益等支付信息 c. 提示 3：由于该类订单的运费部分由平台补贴，三方暂时无法感知运费数据，请提示商家前往千牛查看，文案建议：可前往千牛后台-订单管理，查看送礼订单的运费信息 —————————————————————— 3. 操作区屏蔽：收货人确认收货地址后，面向付款人和收货人的能力存在差异，比如仅支持付款人开票、仅支持收货人退货退款，其他操作请 ISV 谨慎评估是否需要屏蔽；官方面板中，核对订单、小额打款、小额收款、协商发货、帮他退款均保持禁用，供三方参考 |
面板改造示意： |
ERP产品 订单工具 |
1. 公告提示：由于收货人确认收货地址前，三方无法感知订单存在，因此 ERP 需要在工具面板中提供公告区域，声明如果出现这类资讯需求前往千牛后台查看，参考的公告内容：由于存在付款人和收货人不一致的订单类型，在收货人确认收货地址前，暂时无法获取相关订单，如有问题请前往千牛后台-订单管理处理 —————————————————————— 2. 付款人和收货人信息展示： a. 在订单列表上，可以展示订单对应的付款人和收款人，使用模糊化的淘宝 nick，具体字段已在上文给出 b. 在订单详情中，可参考图示展示付款人和收货人信息，并增加提示，告知商家严禁将付款人和收货人信息告知对方 i. 送礼订单提示：订单的付款人和收货人不同，发货及售后问题请联系收货人；发票问题请联系付款人 ii 买家信息提示：为保障用户信息及隐私，请勿对收货人（收货人nick）擅自透露订单的支付账号、优惠权益等支付信息 iii. 物流信息提示：为保障用户信息及隐私，请勿对付款人（付款人nick）擅自透露订单的收货地址、物流轨迹等信息 |
ERP 或 订单工具示意： |
由于运费数据部分 ISV 无法获取，部分基于订单总价的产品策略需要评估是否提醒商家或屏蔽。
4. FAQ
Q：订单没有立即推送的情况（hold 订单），拿不到订单怎么办？
A：由于订单的特殊性，收货人确认收货地址前，不会推送订单（API查询会返回“交易截单”信息），目前 hold 单时长最多不超过 24 小时，超时会自动关闭（关闭后的订单和对应的退款单也不会下发，单据不会向生态同步）；同时由于在生态 ERP 和工具看不到该订单，建议让商家能够感知到该订单并且在千牛后台进行查看。
Q：同一个付款人在当日同一个店铺内买了两个商品，在收货人相同的情况下，两笔订单的OAID是否一致？
A：以上场景两笔订单的OAID一致。
Q：此类订单 OAID 合单的逻辑变化？
A：该类型订单不要和普通订单做拆合单，以免出现无法预知的问题，这个拆合单只能必须整单发,不允许与同类型合并,也不允许拆分发货。
Q：消息下发的情况，是否有调整？
A：收货人确认收货地址前，订单处于hold单状态，交易创建、支付消息不会下发。
Q：该类型订单是否支持改地址能力？
A：不论是在ERP侧或者官方后台均不支持此类订单修改地址，但后期会考虑开放。
Q：收货人没有填写地址时，超时自动取消或者付款方退款，售后单和订单是否还会下发？
A：没有地址信息的时候不会下发，超时关单也不会下发。
Q：如何获取该送礼订单的运费数据？
A：当前该类型订单的运费由官方补贴，接口中暂不推送运费数据，请提示商家前往千牛查看，文案建议：可前往千牛后台-订单管理，查看送礼订单的运费信息。
Q：不同订单状态下售后订单处理的角色和规则？
A：收货人确认收货地址前，三方无法获取订单信息，以引导到官方处理为主，同时该阶段中，仅付款人可以进线咨询订单售后问题；收货人确认收货地址后，付款人和收货人均可进线咨询，两者能够处理的售后问题存在差异。
Q：送礼订单是否支持拆合单？
A： 由于业务的多样性和系统的差异化，针对服务商系统处理送礼单的拆合单场景，平台侧只提供建议但不做为标准依据，服务商侧需要根据自己作业和业务实际情况做选择性参考：
① 非送礼订单和送礼单是否能合单：
为了体现送礼的业务场景效果，我们建议普通订单和送礼订单不要合单发货，保持业务场景上的区分。
② 多笔送礼订单之间是否能合单：
a:如果送礼订单OAID一致的，可以考虑合单节省运送成本
b:如果在同一店铺下购买的送礼订单OAID不一致，但是实际收件人信息、收货地址一致的订单理论上可以合单发货。
③ 送礼订单拆单逻辑：
为了保证送礼业务场景和业务效果一致性，我们建议一个送礼订单下的商品尽量不要拆单发货。
如若送礼订单的具体商品内容，确实无法满足在一个包裹里完成履约。服务商和商家为了保证履约，在业务理解一致的情况下通过拆单分包裹发货形式解决。
三、预付邮费模式
淘宝送礼能力上线后，平台即将更新送礼运费逻辑，从【平台垫付邮费】切换为【送礼人预付邮费】或【收礼人支付邮费】的方式，在这两种场景下，会涉及到邮费费用的预付、退差。
1. 场景介绍
场景 1：送礼人预付邮费
该场景下，送礼人下单时，平台会要求送礼人支付预付邮费，在收礼人确认收货地址后，计算出准确的邮费金额，再将多余的邮费预付款退回送礼人，此时对商家而言，会出现一笔邮费退差单。
场景 2：收礼人支付邮费
该场景下，送礼人下单时，平台会预先支付预付邮费，在收礼人确认收货地址并支付实际邮费后，将多余的邮费预付款退回平台，此时对商家而言，会出现一笔邮费退差单。
对于生态，平台会在收礼人确认收货地址后、安全审核结束后、邮费退差完成后，结束 hold 单，因此感知到订单时，邮费确认和退差已经处理完毕。可参考下文中的改造方案完成改造适配。
2. 数据模型和能力变更
请服务商确认产品中以下接口的使用。
以下 api 变更预计于 1 月 21 日上线，上线后即可进行适配。
类型 |
接口 |
正向交易 |
taobao.trade.fullinfo.get taobao.trades.sold.get taobao.trades.sold.increment.get taobao.trades.sold.incrementv.get taobao.trade.simple.get taobao.trade.get taobao.trades.simple.sold.get taobao.trades.simple.sold.increment.get taobao.trades.sold.history.get taobao.open.trade.get taobao.trade.fullinfo.get.vo taobao.trade.fullinfo.get.customization |
以上API接口出参会增加如下的字段信息：
字段 |
描述 |
类型 |
备注 |
post_fee_type |
邮费类型 |
string |
邮费类型 giftprepaid 代表送礼玩法预付，此时下面三个字段需要被识别使用；normal 代表普通订单 buyer 付款邮费或平台包邮订单。 |
real_post_fee |
实际支付邮费金额 |
string |
实际邮费 单位：分 没有发生邮费退差不返回该字段 |
refund_post_fee |
邮费退差金额 |
string |
邮费退差金额 单位：分 没有发生邮费退差不返回该字段 |
gift_post_fee_role |
邮费支付的角色 |
string |
送礼邮费支付角色 0为送礼人支付邮费；1为收礼人支付邮费 免邮场景、平台补贴邮费场景不返回该字段 |
post_fee_type 为 giftprepaid 时，原字段 post_fee = real_post_fee + refund_post_fee
数据推送交易的同步字段配置会增加以上4个字段（默认选中，不用单独配置）；相应的数据通过大字段的形式写入到jdp_response中。对应的表为：
sys_info库表 |
类型 |
jdp_tb_trade |
订单 |
邮费退差的退款单在消息服务、数据推送和普通退款查询接口（taobao.refund.get、taobao.refunds.receive.get等）是屏蔽的，需要通过“送礼退款单”接口 taobao.special.refund.get、taobao.special.refunds.receive.get查询，同时邮费退差单refund_id、refund_status等在交易接口上也不会有体现。
taobao.special.refunds.receive.get 会新增一个入参 biz_claim_type，指定邮费退差 RETURN_PART_POSTAGE 类型时，才返回邮费退差单，未指定邮费退差类型时默认不返回邮费退差单信息，服务商在完成改造后，可以传入指定参数类型获取此类单据。
3. 邮费表达优化
产品类型 |
优化建议 |
参考效果 |
前台表达 客服面板 ERP |
1. 由于三方感知到订单的时候，邮费确认和退差已经处理完毕，因此只需要展示最终的状态即可 2. 邮费退差单会成为一种特殊退款类型，在普通退款接口中我们会屏蔽查询，数据推送也不会推，请使用 special 接口查询 3. 图中的单号来源为邮费退差单，即从第二点提到的 special 中查询获取 |
客服面板产品展示示例： 订单类工具展示示例： |
4. 开票能力优化
主要面向 ERP
1. 由于运费变动，平台提供的开票数据会随订单状态更新，推荐使用 taobao.trade.invoice.summary.get
a. 注意：创建订单时间在 2024.1.1后的订单可以用本接口查询金额
b. 接口中的开票金额更新规则如下：
i）收礼人确认收货地址前：开票金额 = 货款 + 预付运费
ii）收礼人确认收货地址后：开票金额 = 货款 + 预付运费 - 邮费退差
iii）如有退货退款：开票金额 = 货款 + 预付运费 - 邮费退差 - 退款
c. 请结合订单状态（建议发货后或确收后允许开票）确认是否允许开票以及相应的开票金额
2. 避免使用 taobao.trade.fullinfo.get 交易接口，按买家实际支付金额开发票，该接口金额在某些场景下不等于实际开票金额，使用 payment 字段作为开票金额可能导致资损 【如果使用交易接口金额开票，需要在1.21号前完成改造，切换为开票金额查询接口】
说明：
① 使用开票申请消息 + alibaba.einvoice.apply.get接口不受影响；
② 如继续使用 taobao.trade.invoice.amount.get 获取开票金额，暂时也不会受到影响；
③ 本次改造主要是针对使用 taobao.trade.fullinfo.get 的金额作为开票金额依据的服务商，交易接口返回的金额不能完全作为开票金额，部分场景下可能出现不准确的情况。
5. FAQ（持续更新中）
Q：收礼人付邮费场景下，收礼人如何开邮费的发票？
A：2025.1.6 - 2025.1.21之间的订单邮费为消费者承担，若是付款人承担，则给付款人开票的金额里面会包含邮费金额；若是收货人承担邮费，如收货人需要发票，需要收货人联系商家线下开票，线上无申请入口。
