分销商接入艺龙开放API时会因为有些逻辑不规范导致赔付的出现，以下是需要重点关注的CASE，分销商产品、开发、测试的同事都需要关注下。

1.     特殊早餐逻辑

RatePlan节点会关联多个ValueAdd规则，需要关注TypeCode为99的ValueAdd规则，即特殊早餐规则，在其有效日期内，会覆盖掉原有的TypeCode为01的普通早餐规则，如果发现用户预订的时间段中某一天或几天符合TypeCode为99的ValueAdd中的有效日期判定，那么这一天或者几天的早餐数量需要取特殊早餐规则中的数量，而非普通早餐规则中的数量，否则引起的投诉、损失将由代理自身承担。

2.     货币类型

艺龙报价接口（比如hotel.list、hotel.detail和hotel.data.rate），吐出的价格为原币种价格，展示给客人时，需要告知客人这个货币类型和价格，比如100美元、300港元等等，成单时传入的总价和对应的货币类型也都是原币种的，成单后的逻辑，比如订单详情接口中的总价、罚金、退款等金额相关的字段，如果有吐出对应的货币类型，那么就是对应币种的价格，如果没有吐出，那么一律按照人民币价格处理。

3.     RoomId和RoomTypeId

这两个对象也是分销商很容易混淆的概念，详细的说明在http://open.elong.com/faq/detail?id=157&plt=2的第一大节有说明，成单时传入的是RoomTypeId，而非RoomId，否则很容易出现无法下单或者下单后房型不对引起投诉。

4.     重单

艺龙侧的重单判定逻辑非常弱，需要分销商自己来判定是否重单，重单的判定逻辑在成单接口（hotel.order.create）文档上有说明，分销商据此来进行判定，否则用户重复进行成单操作造成的重单也由代理来负责。艺龙一般只根据分销商传入的AffiliateConfirmationId字段来判定是否是同一个订单。

5.     预订限制

除了RatePlan节点关联的BookingRule会要求一些限制信息外，RatePlan节点本身也有一些限制信息，比如MinAmount表示成单时最少预订多少间房，MinDays表示最少预订多少天，MinAdvHours表示最少提前多少小时预订等等，具体的字段及使用说明请详细阅读文档相关字段。

6.     关于成单前的校验

无论是离线数据模式还是实时搜索模式，其获取数据均从艺龙的缓存中获取的，而艺龙的数据可能会与供应商系统的数据有延迟，比如供应商某个房型产品的价格从200变为100，但是艺龙侧的缓存数据还没更新，那么分销商获取的价格依然会是200，这时就需要通过校验接口hotel.data.validate或者hotel.data.booking接口来获取最新的产品信息，这两个接口都是直接调用供应商的接口，所以获取的数据和供应商一致，我们建议在成单前进行一次调用来校验价格、库存等信息。

其中库存还好，库存不够最多客人成单失败，但是价格错误的话成单有可能通过，从而引起客人投诉。

另外，hotel.data.validate接口仅校验库存和价格，如果对规则信息（包括预付规则、担保规则、预订规则、ValueAdd规则）也要校验的话，那么就需要调用hotel.data.booking接口。校验规则主要是可以避免因为艺龙数据延迟造成的预付规则、担保规则还有早餐数量不一致的情况。其中预付、担保规则错误可能导致成单后取消时间变化，甚至原来可以取消的订单变为不可取消。ValueAdd规则延迟可能会导致查询到有早餐，但是因为酒店刚维护了特殊早餐，而艺龙没有获取到，特殊早餐覆盖掉普通早餐导致用户查询到有早餐而实际没有早餐。

本条逻辑并不容易测试，仅产品、开发的同事关注下并按照这个逻辑设计即可。

7.  关于酒店服务时间

有些酒店会有营业时间的限制，比如只在12点到22点可以处理订单，这样用户下单时间（即预订时间）需要做约束，否则加入用户在第二天凌晨1点预订或者在当天12点前预订，发现订单一直不给处理，会引起投诉。这种情况只发生在当天预订当天入住的情况，如果当天预订明天或者更晚的日期，那么不需要处理，依然可以把这个产品展示给用户。服务时间字段参考RatePlan节点的serviceTimePolicyInfo字段。