这两种规则节点，大致需要分两部分来看。第一部分是判断规则是否有效，第二部分就是取消逻辑了，第一部分其实就是讲第二部分是否生效的。大体上讲，预付和担保规则都可以认为是取消规则，只不过其字段不同所以分了两类。

这两种规则节点，都会包含编号、描述、日期类型、开始日期、结束日期、周有效天数这几个字段，其中编号是用来让RatePlan关联使用的，表示这个RatePlan使用了哪个担保或者预付规则。描述字段，只需要直接展示给用户即可，如果觉得这个描述不好，那么分销商可以自己根据这个规则节点的其他字段进行解析。
至于开始日期、结束日期、周有效天数，是说当前时间是否在开始到结束日期范围内，当前时间的星期数是否在周有效天数内，只有这两点都满足，这条规则才是有效的，否则可以忽略这条规则。需要主要的是，如果使用hotel.list和hotel.detail接口，那么这三个字段就不必判断了，因为我们已经根据接口调用的时间判断过了，只有有效的才会返回。

接下来就需要分开来看担保和预付规则了，我们先说比较简单的担保规则。

担保规则后面的字段，一类是判定规则是否生效，一类是判定成单后的取消规则。

担保规则是否生效判定逻辑如下，首先是IsTimeGuarantee和IsAmountGuarantee这两个字段，表示是否是时间担保和是否是房量担保。如果二者均为false，那么为强制担保，即不论如何都生效，往下继续判断取消逻辑即可。如果不是都为false，那么需要判断哪个为true，那么就判断哪个的逻辑，如果都为true，那么就既判断到店时间，又判断房量。如果IsTimeGuarantee为true，那么就判断用户的最晚到店时间是否落在StartTime和EndTime之间，如果是，那么该规则就生效，另外IsTomorrow表示的是EndTime的时间是否是到店日期的后一天的时间。如果IsAmountGuarantee为true，那么需要判断用户订的房间数量是否大于等于Amount字段，如果是，那么规则生效。

担保规则节点的剩余字段就是取消规则了，首先是GuaranteeType字段，表示需要交纳的担保金额的数量，目前只有首晚和全额，注意这里的金额仅仅是订一间房的担保金，如果订多间那么担保金额需要乘以房间数量。ChangeRule表示的是取消规则类型，NoChange是不可取消，NeedSomeDay要和后面的Day和Time两个参数结合来看，表示在到店日24点的前Day天的Time时之前可以取消，NeedCheckin24hour需要和Hour参数结合来看，表示在到店日24点前Hour小时可以取消。需要注意的是，Day和Hour这两个参数的数值可能非常大，比如Day可能是三百多，Hour可能是2万多（比如常见的23988），这种情况属于正常情况，根据正常的逻辑判断就可以，比如Hour是23988时，那么就表示在到店日24点前23988小时之前可以取消，如果觉得这样的提示不友好，可以追加一个判断，那就是看向前推这么长时间后，这个时间点是否小于当前时间，如果小于当前时间，那么就直接告知用户不可取消就行了。

然后来讲一下比较复杂的预付规则节点的使用。

预付规则没有需要交纳多少金额的字段，因为预付产品本身就需要全额支付，我们只需要关注取消逻辑就可以了。首先是取消规则类型ChangeRule字段，这个包含了三种不同的取消逻辑，第一种是1、PrepayNoChange不可取消，不需要介绍，其他两个比较复杂，下面详细介绍。

2、PrepayNeedSomeDay，这种取消规则，很复杂，实质上是一种三段式的取消逻辑，Hour和Hour2两个字段，分别表示了到店日24点向前推Hour小时和向前推Hour2小时两个时间点，第一个时间点前（即到店日24点前Hour小时之前）的取消逻辑一般是免费取消的，但是最好还是判断下DeductFeesBefore，如果DeductFeesBefore为1，那么还是需要收取罚金的，罚金就是说退款的时候不会把预付的钱全部退还，而是减去罚金后退回，这个罚金的数目要根据CashScaleFirstBefore和DeductNumBefore判断，再具体的就不说明了，一般人都会用。然后是第二段时间（即到店日24点前Hour小时至到店日24点前Hour2小时之间），这段时间内大多数情况是会收取罚金的，和第一段时间一样，先判断DeductFeesAfter是否为1，然后根据CashScaleFirstAfter和DeductNumAfter判断罚金数量。第三段时间（即到店日24点前Hour2小时至到店日24点），这一段时间就不可取消了，实际上到店日24点之后也不可以取消的。这里需要注意的地方是，Hour的数值可能很大，比如23988，同样处理即可，如果判断到店日24点前Hour小时小于当前时间，那么就说明第一段时间不可取消了，还有第二段时间的罚金计算后可能发现是全额的百分之百，或者数值和酒店产品的价格相等，那么也可以解析告知用户这段时间不可取消。另外一个值得注意的地方是Hour2可能为0，这样的话第三段时间实际上就不存在了，至于怎么描述给用户，开发的同学不懂可以问你们的产品，产品的同学不懂那也不要找艺龙，已经描述的清楚的不能再清楚了。

3、最后一种预付取消规则PrepayNeedOneTime，这种规则只有两段时间，不需要根据到店日来推，只需要判断DateNum和Time字段即可，描述为在DateNum的Time时前可以免费取消，之后不可取消。很简单，唯一要注意的还是DateNum的日期可能很久远，比如1970-01-01或者2001-01-01这种的，不要问为什么，还是判断这个DateNum+Time的时间是否小于当前时间，小于当前时间说明永远不可取消。

注意：以上都是hotel.detail和hotel.list接口的规则用法，这两个接口每个RatePlan节点只会关联一个规则，但是离线数据模式中的hotel.data.rp接口会关联多个规则，这个时候情况比较复杂，如果遇到请联系我们产品。其实对应接口文档也有说明优先级判定，简单来讲就是每段时间都取最严。