先判断RatePlan节点中ValueAdds是否不为空，不为空说明有关联增值服务，其中最重要的就是早餐规则。早餐规则有两种，通过TypeCode区分，01表示的是普通早餐，不需要判断有效日期和周有效天数，RatePlan节点有效这个早餐就有效。
但是，TypeCode为99的特殊早餐，会覆盖用户预订日期范围的部分或者全部早餐规则，99特殊早餐需要判断有效日期和周有效天数，如果发现用户预订日期范围内的天数满足特殊早餐的有效日期和周有效，那么这一天就不使用TypeCode为01的早餐，而使用TypeCode为99的特殊早餐。预订日期范围内不满足有效日期和周有效判定的，才会使用普通的01早餐。
注意，TypeCode为99的ValueAdd规则可能会有多个，需要依次判断每个这样的ValueAdd节点。
以上是每天应该采取哪种早餐规则的判定，下面说一下ValueAdd其他字段的使用，首先是是否包含在房费中，指的是该规则所指定的增值服务（比如早餐）是否需要额外付费，如果为false，那么需要客人到酒店前台付费才能领取早餐，其实等价于就是不含早餐。
Amount指的是在IsInclude为true，也就是包含在房费中时，包含的早餐数量，下面的价格和货币类型不用多说。
最后是单加IsExtAdd，这个字段其实不解析也没事，这个指的是除了包含在房费中送的早餐外，在酒店前台是否可以再多点一份或者几份，每份价格是多少，和接口逻辑没有任何关系，成单接口也不支持传入单加。
    以上就是早餐规则节点的使用说明了，讲解应该还算比较清楚。
    查询使用的是hotel.data.rp或者hotel.detail接口，这个接口查询的是艺龙从供应商那里缓存的数据，这个数据艺龙并不能保证百分百和供应商同步。
    Hotel.data.booking接口是实时调用供应商，所以这个接口返回的数据肯定是实时的，如果出问题也是供应商的问题。
    试单指的是抽取一些酒店来定期执行hotel.data.booking接口，但是这样其实没用的，周期过长会导致数据依然不准确，周期太短会击垮我们供应商的服务，而且也没办法保证全覆盖。
所以艺龙这边建议是在用户进入订单填写页，或者在分销商认为合适的时机，调用一下hotel.data.booking接口，判断是否和用户看到的信息一致，不一致则需要提醒用户。这里判断的不只是早餐规则，还有预付规则和担保规则，以及库存和价格。
以上。