扫码通3.7.0_3.8.0产品简报

适用版本：XMS所有客户
1.产品说明
1.1 产品亮点
1.2 版本要求
1.3 功能清单
2.产品介绍

适用版本：XMS所有客户

1.产品说明

1.1 产品亮点

排队预点餐：类似社会餐饮，排队等位时客人可以先预点餐，方便入座后快速下单，进而也增加酒店的翻台率
后付叫餐模式：满足客人因为等人等一些原因，需要下单后稍后出餐的需求
客房身份校验：后置身份校验逻辑，为了满足客人在不校验的情况下就可以先了解有哪些美食和服务
欢乐时光价：解决扫码通订单无法享受欢乐时光价格的问题
外卖模式：满足酒店外摆需求，支持自取和配送两种方式，有效增加酒店营收

1.2 版本要求

1.3 功能清单

排队预点餐
二维码收款，非入账模式
后付叫餐模式
单个菜品必选烧法
不可点菜品显示优化
客房身份校验优化逻辑
Redis缓存优化
同步XMS交易记录的模块归类
欢乐时光价
外卖模式

2.产品介绍

2.1 排队预点餐
2.1.1 说明
● 支持场景：餐饮场景
● 典型业务：类似社会餐饮，排队等位时客人可以先预点餐，方便入座后快速下单，进而也增加酒店的翻台率
● 典型客户：北京新疆大厦
● 适用UI：新UI
● 预点二维码：是固定二维码，无需绑码，后台有两个入口可以打开二维码，均由权限控制是否显示
○ 西软点菜-营业点-预点餐二维码
○ 扫码通-二维码-餐饮-选择具体营业点-预点餐二维码
● 小程序端：流程如下
○ 扫码后逻辑跟普通二维码一样，已存在购物车就到点餐页面，没有购物车则到首页选人数
○ 点菜页没有下单功能，但支持扫桌码（下单按钮位置=》扫桌码），逻辑跟微信扫码一样
○ 入座后扫具体桌号码，进入到首页（桌号码还没有输入过人数）或点菜页后，判断客人有没有预点菜，如果有，则提醒“您有预点菜品，是否需要立即同步至当前餐桌？”
■ 稍后同步，不做任何动作，客人照常在桌号码购物车上点菜，再次扫桌码时会继续提醒是否同步
■ 立即同步，则将预点菜追加到桌号码购物车中，包括人数和备注
■ 人数：如果桌号码购物车已经选过人数，则以该人数为准，否则使用预点购物车的人数
■ 备注：也是追加方式，将预点购物车的备注追加到桌号码购物车上

2.1.2 展示
图一

图二

图三

2.2 二维码收款（不入账）
2.2.1 说明
● 支持场景：二维码收款
● 典型业务：满足客户仅仅是希望为某一些营业点提供一个二维码来完成收款的需求，营收不需要入业务系统。
● 典型客户：明水古城
● 适用UI：新UI
● 后台，绑码逻辑调整：
○ 入账模式：二维码绑定了菜品
○ 非入账模式：二维码未绑定菜品
● 绑定到营业点，则表示收入算具体营业点的
○ 绑定到酒店，则收入算整个酒店
● 小程序：
○ 入账模式，按之前的逻辑不变
○ 非入账模式
■ 有营业点则需显示具体营业点
■ 不考虑营业点的服务费茶位费等，没有意义
■ 金额由客人手工输入
■ 支付
■ 交易记录同步至XMS
■ 值守
○ 后台设置，新增值守模块：二维码纯收款
○ 支付记录列表及详情查看，列表只查消费记录
○ 消息通知：弹窗、语音、小票等，这里要注意的是，不管是弹窗语音还是小票，都是叫二维码收款，而不是二维码纯收款，新增模块只是为了区分，且酒店正常情况都会是二选一，要么入账要么不入账
○ 退款，含权限
○ 退款日志，可以查看该笔消费的全部退款记录

2.2.2 展示
图一

图二

图三

图四

图五

图六

2.3 后付叫餐
2.3.1 说明
● 支持场景：餐饮场景、客房场景
● 适用UI：新UI
● 典型业务：满足客人因为等人等一些原因，需要下单后稍后出餐的需求
● 后台设置：西软点菜-营业点-叫餐类型
○ 适用于后付不审核模式
○ 类型选项有三种：
■ 即起，默认，下单后立即厨打
■ 仅备注叫起，下单后立即厨打，但是本次下单菜品都会备注上“叫起”，厨打单相当于做备菜单，然后有服务员人工喊话去起菜
○ 设置联动逻辑
■ 先付模式开启时，审核关闭，叫餐类型重置为即起，且均置灰不可改
■ 先付模式关闭时，审核跟叫餐类型都可改
■ 审核关闭时，才允许叫餐类型可选
■ 审核开启时，叫餐类型置灰不可选，且重置为默认即起
● 小程序：
○ 当叫餐类型是“仅备注叫起”时，每次下单或加菜均会提醒“是否立即出餐？”

2.3.2 展示
图一

图二

2.4 必选烧法
2.4.1 说明
● 适用UI：新UI
● 典型业务：有些客户海鲜的菜品做法特别灵活，菜品管理里面只有一个材料的名称比如鲈鱼，点餐时需要搭配烧法来进行制作，这就要求点菜时不能错过烧法的选择
● 后台设置：分两处
○ XMS端，菜谱管理-菜品属性-必选烧法，设置后mob需同步菜谱生效
○ MOB端，西软点菜-通用配置-菜品烧法必选
● 小程序端规则如下：
○ MOB端开启，则不管XMS端是否设置了必选烧法属性，只要绑定了的烧法都是必选
○ MOB端未开启，则看XMS端具体菜品必选烧法属性，勾了就必选，不勾就非必选

2.4.2 展示
图一

图二

图三

2.5 不可点菜品显示优化
2.5.1 说明
● 支持场景：全场景
● 典型业务：有些菜品可能估清了或者下架了，有些客户希望不要展示这些菜品，以免干扰客户的点餐体验。
● 适用UI：新UI
● 后台设置：扫码通-通用配置，增加开关控制是否隐藏不可点菜品
● 小程序端显示规则：
○ 开关关闭，默认，不可点菜品放到每个相应菜类最后且折叠显示
○ 开关开启，隐藏不可点菜品
○ 不影响菜品原有已经存在的显示开关设置，如海鲜菜不可点等
○ 隐藏非营业时间菜品，在显示菜品的情况下，也调整为折叠显示
● 不可点菜品包括但不限于：
○ 菜品已被锁
○ 菜品已沽清

2.5.2 展示
图一

图二

2.6 客房身份校验优化
2.6.1 说明
● 支持场景：客房场景
● 典型业务：对于线上支付的的流程，尽量简化身份校验，提升交互友好度。
● 适用UI：新UI
● 小程序端规则如下：
○ 点餐，在支付时进行验证
■ 选择”挂房账”和0金额的时候需验证
■ 其他现结方式无需验证，如微信支付宝
○ 送物服务
■ 免费服务的提交需要验证，防止恶意刷单
■ 收费服务的提交无需验证，因为需要客人支付，已经避免了恶意刷单的风险
○ 迷你吧
■ 下单时无需验证
■ 但支付时，任何支付方式都需要验证，因为账务需要挂到房间账
○ 我的账单，进入时就需要验证
○ 住中开票，进入时就需要验证
○ 停车服务，进入时就需要验证，添加车牌是绑定到账号，同时需要通过账号获取已添加的车牌号
○ 评价
■ 客房评价，进入时就需要验证
■ 其他订单评价，无需验证
○ 其他功能，统一规则如下：
■ 自定义功能，无需验证，因为自定义的都是查看业务，不会影响酒店日常运营
■ 需要入房间账或查看房间账的，必须验证
■ 部分功能目前还使用老UI页面，均暂时保留进入时就验证，如：预约打扫、自助报修、投诉与表扬、发票预约
2.6.2 展示
以客房送餐为例

2.7 Redis缓存优化
2.7.1 说明
● 支持场景：全场景
● 适用UI：新老UI
● 缓存键值格式调整，将缓存功能提到第二级目录，以营业点为例，从之前的SMT-商户-酒店--pccode，调整为：SMT-pccode-商户-酒店-
● 优化逻辑：
○ 缓存大小，尽量精简不必要的缓存数据
○ 缓存释放，及时释放临时缓存，避免出现永久存在
2.7.2 展示

2.8 XMS交易记录的模块归类
2.8.1 说明
● 支持场景：全场景
● 适用UI：新老UI
● 目的：为了配合xms对交易记录的归类管理，统一后方便查看和统计
● 最低支持XMS版本：XMS-V4.6.0-202506111206
● 对接该版本之前的XMS，模块还是和原来一样全部归类到99
● 归类规则如下：
○ 餐饮
■ 点餐 94
■ 客房送餐 94
■ 收款二维码（入账模式） 94
○ 客房
■ 迷你吧 93
■ 送物服务 92
■ 房间账单 92
■ 会员储值 112
○ 预订
■ 餐饮预付款（康养） 95
■ 前台押金（非扫码通业务，不含在本次测试内） 92
○ 其他
■ 收款二维码（非入账模式） 99
2.8.2 展示
2.9 欢乐时光价
2.9.1 说明
● 支持场景：餐饮、客房送餐
● 适用UI：新UI
● 典型业务：有些特殊时段，可能会需要做活动吸引客户或者有可能因为人流较多，可以提升收益，将某些时段的价格调高处理。
● 具体效果跟pos中一样，规则起效的菜品，将会用欢乐时光价格替换掉原价格
2.9.2 展示
图一

图二

图三

2.10 外卖模式
2.9.1 说明
● 支持场景：餐饮
● 适用UI：新UI
● 典型业务：最近特别火的酒店外摆业务的线上点餐后取餐的业务支持
● 后台设置，营业点设置
○ 总开关，外卖配送
■ 第一版要求场景：一台多单、先付、普通场景模式
○ 外卖方式，自取和配送，可同时开启
■ 自取
■ 当天自取的最晚点餐时间，问号说明：超过该时间点下的订单不支持当天取餐
■ 支持自取的天数，问号说明：从当天算起客人可选择该范围内的某一天进行取餐
○ 第一版仅限今天和明天，后期开放最多7天
■ 自取时间区间
○ 最早时间
○ 最晚时间
○ 时间间隔，固定三个选项（15分钟、半小时、一小时），默认半小时，问号说明：将自取区间划分成多个时间段供客人选择
■ 取餐地址，问号说明：设置后在小程序端订单详情中会显示，方便客人上门取餐
■ 配送
■ 当天配送的最晚点餐时间，问号说明：超过该时间点下的订单不支持当天配送
■ 支持配送的天数，问号说明：从当天算起客人可选择该范围内的某一天进行配送
○ 第一版仅限今天和明天，后期开放最多7天
■ 配送时间区间
○ 最早时间
○ 最晚时间
○ 时间间隔，固定三个选项（15分支、半小时、一小时），默认半小时，问号说明：将配送区间划分成多个时间段供客人选择
■ 最低配送金额，当金额达不到时支付，会提醒客人无法配送
○ 没有自取方式，“订单金额未达到100.0元，不支持配送”
○ 有自取方式，则“订单金额未达到100.0元，不支持配送，如不再加菜可换成自取方式下单”

○ 餐厅联系电话
■ 配置后，小程序端订单详情页会显示电话图标，支持客人拨打联系餐厅
○ 餐具增加开关控制，“是否支持客人选择餐具”
■ 通用逻辑，新UI所有模式都适用
■ 默认关闭，也就是新同步的营业点将默认不支持选择餐具
■ 现有的营业点，默认开启，兼容原有逻辑
■ 关闭后
■ 待支付界面不再显示餐具选项
■ 修改人数也不会把餐具同步到订单备注中
■ 值守小票也不打印餐具
● 小程序端
○ 登录时，如果开启了外卖配送总开关但两种外卖方式都没启用，则提醒需设置至少一种外卖方式
○ 首页开始点餐，支持选择外卖方式、用餐日期和时间、餐具，第一版，只需人数（餐具）选择，其他不要
○ 点菜页提示信息调整为静态显示，且支持查看完整信息，第一版，仅支持外卖模式
○ 待支付页
■ 显示客人已选择的外卖信息
■ 没有收货地址时，可以快速新增收获地址，保存后就选为送餐地址
■ 没有选过自取或配送时间，默认选中首个可选时间
■ 第一版，关于自取配送日期的限制说明（固定规则，没有设置项），只能有一天可选，按12:00节点为例，今天12点之前的订单只能今天取餐，12点之后的只能明天取餐
■ 支持客人重新选择外卖信息
■ 支付时判断外卖信息是否齐全，不全时需提醒客人补全，补全后才能支付
○ 支付成功的详情页
■ 显示客人外卖信息
■ 自取方式
■ 显著显示取餐号（含条形码），由营业点-取餐核销开关控制，开启时才有
○ 取餐号规则变动：仅限外卖模式，考虑到同一天可以有多天的预订，仅流水号会导致重复，所以格式调整为“日-营业点流水号”，如24-12、24-8、1-5
■ 取餐时间
■ 取餐地址
■ 配送方式
■ 固定标题：待商家配送
■ 没有取餐号，不管取餐核销开关是否开启都不显示
■ 配送时间显著显示
■ 说明配送可能存在延迟的风险
○ 收获地址管理
■ 新建
■ 地图选位置（包括选市区），第一版仅支持手输
■ 地址内容：具体地址、姓名、性别、手机号
■ 修改
■ 删除
● 值守
○ 订单详情，增加外卖信息的显示
○ 弹窗提醒
○ 声音提醒，“有新的外卖订单，请及时处理”
○ 票据打印
■ 单据标题：外卖取菜单
■ 抬头打印取餐号，由营业点-取餐核销开关控制，开启时才有，且不管自取或配送都会打印取餐号
■ 自取时，取餐号给客人核对
■ 配送时，取餐号给骑手核对，第一版没有骑手APP
■ 尾部显示客人外卖信息
■ 台位加粗打印，方便按不同微信群整理取菜单
■ 尾部增加打印订单备注，粗体
● POS
○ 外卖销售报表下•
■ 第一版，根据当天自取或配送的截取时间做结点，统计昨天该时间之后的销售+当天该时间之前的销售，作为当天的全天销售数据