V3.2.0餐饮报表优化

升级时间：2022-3-2 15:30-16:30

升级影响：新增预订权限功能，基于已发生预订订单用户，需技术员一对一联系用户协助设置预订权限。 待联系名单详见第7点

本次升级主要解决部分业务底层数据存储逻辑与历史数据处理，为接下来的报表优化统计做数据准备，对现有业务功能使用无影响

1、“改价”功能，原单价逻辑调整

优化背景：改价优惠菜，目前原单价存储的是后台设置的价格。当做报表数据计算时，需额外判断是否为改价优惠菜，“是”则取折后价，不能与普通菜按一套逻辑。       

影响：增加了统计难度（目前当为改价优惠菜时，取折后单价。反之取原单价。对用户使用暂无影响）；数据量大对性能也有一定影响；扩展性不强，对新报表统计不友好

新逻辑：改价可以理解为按一个新价格卖给顾客，不算是对菜品打折。改价后原单价与折后单价一致，为改后单价

历史数据：批量更新。“改价优惠菜”，原单价=折后单价，包括套餐明细菜

2、“套餐菜”改价/打折/全单优惠/恢复原价/赠菜时，套餐明细菜原单价与折后单价逻辑调整

优化背景：套餐明细菜的价格需根据套餐菜的配比关系，分摊至套餐明细菜。 目前当套餐明细菜配比关系大于1时，分摊计算错误。       补充：后台管理--菜品管理--新增套餐，菜品不允许选择套餐菜（目前是套餐中含套餐，导致数据显示与统计异常）

影响：现有菜品销售明细报表统计错误（现阶段菜品销售明细报表是按套餐明细菜做的统计，需确保数据正确。后期将优化按套餐菜统计，与菜品销售统计报表规则一致）

新逻辑：如下图。仅作为分摊的大概逻辑，具体实现与精确度问题以研发规则为准

历史数据：不做处理。以上新逻辑，只对上线后新产生的套餐数据生效

3、点菜表折前小计与折后小计逻辑调整

优化背景：目前冗余的金额计算错误。        

影响：增加了统计难度（目前是用单价*数量重新计算，对用户使用暂无影响）；数据量大对性能也有一定影响；扩展性不强，对新报表统计不友好

新逻辑：折前小计=折前单价*销售数量，折后小计=折后单价*销售数量。包括改价、打折、赠菜、全单优惠、恢复原价等相关业务

历史数据：批量更新。折前小计=折前单价*销售数量，折后小计=折后单价*销售数量

4、自定义结算/消费科目简称优化

优化背景：自定义结算/消费科目，没有科目简称（只有大类）。     目前交班与报表，自定义结算科目，都统一计算在现金或银行卡中。无法核对实际现金或银行卡账务，账务不清晰。     补充：后台管理--结账设置--结算科目/消费科目，自定义科目时，有效科目名称不允许重复。（目前是没做控制，用户任意定义，导致后期报表统计精度）

影响：增加了统计难度，账务不清晰（目前自定义统计在现金或银行卡中，无法核对实际收款；且有些按科目简称统计，有些按科目大类统计）；数据量大对性能也有一定影响；扩展性不强，对新报表统计不友好

新逻辑：自定义结算/消费科目每个餐饮营业点，有效科目名称唯一，且科目简称唯一。

历史数据：批量更新。现有自定义科目新赋予唯一科目简称，并同步更新支付账单表的自定义科目简称

5、部分收款备注自动处理

优化背景：目前收款没有备注填写功能，部分场景下的收款未记录一些关键信息，核对账务明细时不直观

新逻辑：

①会员注册，需支付卡费的场景下，注册成功后，对应收款备注remark为：会员卡费；

②前台收银，使用储值卡支付时，对应收款备注remark为：“会员卡号：”+卡号，例如：会员卡号：88888（便于知晓对应扣款是哪个会员，目前会员姓名获取不到）；

③收/删除预订金，对应收款备注remark为：“收/退”+支付方式+“订金”，例如：收现金订金、退银行卡订金

自定义结算/消费科目每个餐饮营业点，有效科目名称唯一，且科目简称唯一。

历史数据：不做处理。以上新逻辑，只对上线后新产生的收款数据生效

6、外带开台默认“人数”逻辑调整

优化背景：目前是默认为0，大部分不会去修改默认人数，导致计算人均消费时数据不准确

新逻辑：

①外带开台时，人数默认为1；

②外带开台或普通堂食开台时，限制人数只能输入大于等于1的正整数

历史数据：外带订单且人数为0的，人数统一更新为1

7、新增预订操作权限

具体新增权限如下图：

因无默认权限功能，基于已使用的用户需技术员联系用户协助设置预订相关权限（未设置时，前台收银只有预订列表查询功能，无法完成新增/取消/查看预订等功能）

权限设置路径：见上图

中央管理系统--分店控制--分店权限管理--选中餐饮角色--餐饮权限--预订相关权限。

已使用预订客户：辛苦@雷波安排技术员联系以下餐厅，协助设置预订权限，确保客户可正常使用