饿了么开放平台降级场景订单处理方案

降级订单概述

降级订单：在部分特殊情况下(平台活动大促，系统负载高等)，饿了么为保证订单履约促成交易，订单推送系统会在营销相关字段未生成的时候将值置为 0 或者 null 推送，但是核心的菜品信息一般不会受到影响。

如何识别降级单

推送订单的字段中查看downgraded 的值即可识别降级状况，true为已降级，false为未降级。 平台为尽可能促成交易，会在一部分字段未生成的时候（如活动补贴），将订单生成。 如果需要完整的订单的订单信息，需要事后在降级标记为false时再进行读取。 当此字段为降级标识true的时候会影响本单收入的金额值计算不准确，请开发者务必注意。

降级单影响字段

1. 影响字段(eleme.order.getOrder、eleme.order.mgetOrders)，数组的话值为空，double 类型的字段值为 0：

订单参加活动信息 orderActivities list为空

配送费优惠 logisticsActivity list为空

店铺实收 income

饿了么服务费率 serviceRate

饿了么抽佣服务费 serviceFee

用户使用津贴 allowanceServiceFee

饿了么基础物流费 baseLogisticsServiceFee

时段加价 timeIntervalMarkUpFee

距离加价 distanceIncreaseFee

订单中红包金额 hongbao

餐盒费 packageFee

增值服务费 additionServicePrice

价格加价 pricePremiums

订单活动总额activityTotal

店铺承担活动费用 shopPart

饿了么承担活动费用 elemePart

会员减配送费 vipDeliveryFeeDiscount

订单原始价格 originalPrice

总合计金额 totalAmount

配送费原价 + 餐盒费 deliveryPackageFee

总优惠金额 totalActivityAmount

 

2. 影响字段(type=217)

店铺实收 income

总合计金额 totalAmount

配送费原价 + 餐盒费 deliveryPackageFee

总优惠金额 totalActivityAmount

商户处理方案建议

所有降级单都会在降级结束后可以通过me.order.getOrder/eleme.order.mgetOrders 获取订单详情补足。

降级单一般会很快恢复，但是也存在特殊情况，所以ISV需要使用轮训方式进行查询，轮询可以根据轮询次数增加轮询间隔时间，知道获取到完整订单信息。

降级一般不会影响核心菜品的信息传递，所以在核心菜品信息完整的情况下，应该保证接单率，并能完成门店订单入机出餐，并在降级结束后补充完整订单信息。

如果门店出餐一定要求强依赖降级字段，ISV可以在超时前轮训查询订单信息，确认降级是否恢复，如果依旧没有恢复，可以主动拒单。

建议轮询频率为 15s,30s,1m,3m,30m,8h根据轮询次数增加轮询间隔。在4次间隔后（共耗时4分45秒）若还是没有获取到降级字段，需要确认是否在未接受降级字段的情况接单，或者拒单。

是否需要在降级情况下接单需要考虑：
a. 门店pos是否可以在没有活动金额的情况加正常接单
b. 是否可以通知门店切换为napos接单
c.后续缺失活动字段可否通过接口或其他方式获取补偿

若6中3点都无法支持，建议在4次轮训依旧降级后调用eleme.order.cancelOrderLite直接主动取消订单，避免接单后门店无法正常送餐导致客户投诉。

降级单处理流程

如何测试

该类型订单平台侧还无法发起，建议 mock 调试，POST 发送此类型数据到应用的推送 URL，下面的{"key":"value"}可以改为订单数据，downgraded赋值为 true。

curl -X POST -H 'Content-Type:application/json; charset=utf-8' -d '{"key":"value"}' https://推送URL.com

更新记录

V1.1（2023-06-29）

新增三个字段：totalAmount、deliveryPackageFee、totalActivityAmount

V1.2（2023-12-22）

新增「如何测试」段落

 

FAQ

Q：该场景如何测试？

A：可以手动 post 推送构造的降级单数据到推送 URL，模拟平台推送