冲突介绍

目前只发现存在两种情况冲突

• 远期房态中未来某一天的一个房间已经被排房，在做某个业务时，恰好使用到了这个这一天的这个房间导致远期房态排房上面的冲突。正常情况需要提示“远期房态排房冲突”，并且阻止办理业务。
• 远期房量中某一天的某种房型可售数量已经为0(也有可能是可售数量为1，但是需要预订2间这样的情况)，即售罄，但是在做某个业务比如预订或者从空净房开房时，用到了这一天的这个房型的可售数量，由于该房型已经被售罄，即使房间是空净，是不允许再在这个房间办理业务的。正常情况需要提示“远期房量可售不足”，并且阻止办理业务。

业务相关表

业务一：房态详情-【续住】

测试远期房量可售不足描述：将某个房型未来的某一天全部都预订完，将远期房量中可售数量变成0，然后在房态详情的续住按钮续住这个房型的，续住的天数恰好经过这个房型可售数量0的这一天。正常情况下需要提示“远期房量可售不足！”

测试远期房态排房冲突描述：将某个房间未来的某一天进行排房占用，然后在房态详情的续住按钮续住这个房间直到已经被排房的那天的存在远期房态交叉。正常情况下需要提示“远期房态排房冲突！”
测试结果：【已测试通过】
测试步骤：团单预订–25-28团单已预订排房–登记房态–续住25号–提示“远期房量可售不足！”
延续上一个测试取消其中的一个房间后，不能正常续住

业务二:房态详情-【修改信息】-修改时间

测试结果：可以修改

业务三:业务三:新增个单预订(视觉)

测试远期房量可售不足描述：将某个房型未来的某一天全部都预订完即可售为0但是没有进行排房，在新建一个预订单需要包含可售数量为0的这一天。正常情况下可售数量应该为0
测试结果：【测试已通过】

测试远期房态排房冲突描述：有一个预订在未来的某天已经进行排房，现在新增加一个预订，并且排房，和已经排房的那天存在交叉。正常情况下看不到已经被提前排房的那个房间。（目前是提示存在有冲突）
测试结果：【测试已通过】

业务四:编辑个单预订(视觉)

测试远期房量可售不足描述：将某个房型未来的某一天全部都预订完即可售为0但是没有进行排房，现在预订单需要包含可售数量为0的这一天。正常情况下可售数量应该为0。目前是前端控制提示。
测试结果：【测试未通过】

测试远期房态排房冲突描述：有一个预订在未来的某天已经进行排房，现在新增加一个预订，并且排房，和已经排房的那天存在交叉。现在编辑预订单，使得这个这个房间入住和已经排房的那天存在远期房量冲突。（目前是提示存在有冲突）
测试结果：【测试已通过】

业务五:换房（前端业务控制、后端也需要校验）

测试说明：需要进行三项测试，
同房型换房，需要校验目标房型是否存在排房冲突。
不同房型换房，不仅需要校验目标房型的可售数量，还需要校验目标房型的排房冲突情况。

测试同房型换房描述：将一个房间换到同房型的另一个房间，恰好目标房间在未来的某天已经被排房了，目前是排房时候是不能看见另一个已经被排房的房间，不能选择未来某天房间已经被排房的房间。

测试不同房型换房描述：①将一个房间换到另一个不同房型的房间，恰好另一个房型在未来某天房间的可售数量为0，则需要提示冲突“远期房量可售不足”
②将一个房间换到另一个不同房型的房间，恰好另一个房间在未来某天已经被排房了。目前是排房时候是不能看见另一个已经被排房的房间。

业务六:团单-续住/提前

测试远期房量可售不足描述：将某个房型未来的某一天全部都预订完，将远期房量中可售数量变成0，然后在房态详情的续住按钮续住这个房型的，续住的天数恰好经过这个房型可售数量0的这一天。正常情况下需要提示“远期房量可售不足！”
测试结果：【测试已通过】

测试远期房态排房冲突描述：将某个房间未来的某一天进行排房占用，然后在房态详情的续住按钮续住这个房间直到已经被排房的那天的存在远期房态交叉。正常情况下需要提示“远期房态排房冲突！”
测试结果：【测试已通过】

业务十:排房/批量排房（重排、取消、新排）————已经测试发现前端已经完成了校验逻辑。

接口：/partAll

测试批量排房冲突描述：由于选择排哪个房间是走“可预订列表”接口，所以允许排的房间已经在“可预订列表”接口已经过滤掉。所以这里后端没有做任何的处理。

远期房量测试枚举

测试远期房量不足描述（重排相同房型）：原本是A房型已经排房，现在选择重新排A房型另一个，由于原本的预订始终占用着可售，所以不可能存在A房型房量不足情况。注意这种情况下这里不能阻止办理业务。

测试远期房量不足描述（新排相同房型）：原本是A房型没有排房，现在选择排第一次排相同的A房型，有可能A房型的这一间房间未来某天已经售罄，所以正常情况下需要提示“远期房量可售不足！”。

测试远期房量不足描述（重排不同房型）：原本是A房型已经排房，现在选择重新排B房型，有可能B房型未来某天已经售罄，正常情况下需要提示“远期房量可售不足！”。

测试远期房量不足描述（新排不同房型）：原本是A房型没有排房，现在选择排第一次排B房型，有可能B房型未来某天已经售罄，正常情况下需要提示“远期房量可售不足！”。

远期房态测试枚举

测试远期排房冲突描述（重排相同房型）：原本是A房型已经排房，现在选择重新排A房型另一个，可能存在另一个房间未来某天已经被排房。所以正常情况下排到这样的房间需要提示“远期房态排房冲突”

测试远期排房冲突描述（新排相同房型）：原本是A房型没有排房，现在选择排第一次排相同的A房型的另一个房间，有可能另一个间房间未来某天已经被排房，所以正常情况下需要提示“远期房态排房冲突！”。

测试远期排房冲突描述（重排不同房型）：原本是A房型已经排房，现在选择重新排B房型的房间，有可能B房型的房间未来某天已经被排房，正常情况下需要提示“远期房态排房冲突！”。

测试远期排房冲突描述（新排不同房型）：原本是A房型没有排房，现在选择排第一次排B房型的房间，有可能B房型的房间未来某天已经被排房，正常情况下需要提示“远期房态排房冲突！”。

后端逻辑综合

远期房量是否充足判断的前提：知道每次的请求换房都是对应的同一个入住时间离店时间。不能存在有两个或以上的房型入住和离店时间不同，如果存在两个房间存在不同入住时间和离店时间一起提交，比如豪单两间，一间住一天，一间住两天，换成一间豪双，一间豪单，这样就不知道是住一天的豪单换成豪双还是住两天的豪单换成了豪爽，所以请求参数的中明确每个房间换成了什么房型是很有必要的。

检查逻辑优化，将判断远期房态是否冲突放在判断是否更换了房型之前。这样就由原来的四个棱形判断变成了三个棱形判断。

业务十一：维修——暂时不做

维修排房冲突测试描述：维修多天的情况下，如果存在维修的房间未来某一天已经被排房，则需要提示“远期房态排房冲突”，注意这里默认的维修时3天，但是有可能存在超出未来3天的维修的这个房间已经被排房，所以维修的排房冲突校验的时间范围是这个房间未来的所有时间，只要存在排房就会提示排房冲突，并且严格要求需要先取消排房才能够进行维修房间。

维修远期房量售罄描述：维修多天的情况下，如果未来维修的这个房型出现可售数量为0的情况需要提示先处理“远期房量可售不足”先协调远期预订的情况才能够进行维修房间。

业务十三：OTA快速入住

OTA快速入住的房量售罄和远期房态控制是在新增预订时候以及编辑预订的时候，所以这里后端没有做任何的处理。