连锁门店预约履约系统产品系统

连锁门店的预约分散在电话、微信和店员手工登记里，同一档期容易被重复占用。总部无法统一服务项目、价格和退改规则，财务也难以按支付单核对每笔收款和退款。系统面向美容护理、形象课程等按档期到店的连锁门店：总部维护目录和规则，门店只在本店排班里接单、核销，客人用微信小程序或语音确认后写入同一张履约单。

连锁门店里，预约是总部、门店和财务共用的一张履约单。总部统一服务项目、价格和退改规则，门店在自己的排班里接单和核销，财务按支付单核对每笔收款和退款。我独立完成微信小程序、Vue 3 管理端和预约助手。三个入口共用同一组接口，订单状态只在服务端迁移。对话模型可更换，调用时带上该商户已发布的规则。

账号按组织收紧数据范围。总部维护全部门店的目录和价格；店长只看本店员工、排班和订单；店员只处理分给自己的当日队列；财务核对流水、导出报表，不能改排班。导出的手机号按权限脱敏。查询其他门店时，接口直接拒绝。

档期按库存管理。客人提交门店、员工、日期和时段后，数据库事务占用该档期，冲突时返回剩余空档。待支付超时关单并释放档期。应付金额以服务端价格计算。微信支付 API v3 负责预下单和收款，回调同时校验签名、金额和支付单号，同一支付单只入账一次。对不上的回调记入差异台账，订单停在原状态，不能进入待服务。退款沿原支付单发起，完成前保持退款中。核销必须匹配本单核销码，核销人、门店和时间追加进操作记录，原记录保留。

管理端用 Vue 3。总部维护项目和退改政策，门店按星期排班，请假立即扣除可约档期。改约先锁定新档期，成功后再释放旧档期。二级分销记录邀请关系、佣金比例和结算状态，核销完成才入账，退款按原单冲正。每次状态变更都留下操作者、前后状态、原因和时间。

文字和语音走同一条意图识别，语音先转写。可查询服务、查询空档、创建预约、查询订单和取消预约。服务、门店、日期、时段、备注缺任何一项，就返回待补充项并停止创建。服务说明、预约须知和退改政策按商户写入向量库，答复附带条文来源；未命中时说明未查到，并转到详情或人工。内部条文按角色过滤后再进入模型，删除知识须再次确认。信息齐备后，助手复述门店、项目、时间和金额，用户确认才调用同一下单接口。会话保留已确认信息和预约单号，与订单系统只传单号。

预约的小程序、后台和助手是我一个人做的，下单、改约、核销最后都进同一张订单。小程序这边是切门店、选项目和技师、占档、看状态。后台店长可以筛当天的履约队列，导出，改排班和价目；总部管门店介绍，草稿发布以后，小程序上的介绍才会换。助手把一句话拆成门店、项目、技师和时间，这个时段已经满了就改报下一个空档，客人点确认才真正下单。

占档放在服务端。MySQL 用事务把时段占住，后到的请求撞上了，就把还空着的时间返回去，不能把前一单盖掉。短时间连点用 Redis 挡。改约要先锁新时段，锁上再放旧的；中间失败的话，旧档期还留在原单上。待支付超时由接口关单，档期一并还回排班。

微信支付只收服务端算出来的目录价。回调核对签名、金额和支付单号，同一笔支付重复通知只入账一次。金额对不上就记进差异账，订单停在原来的状态。导出的手机号是打码的。店长只能看本店，查别的门店接口会拒绝。

接口用 FastAPI，管理端是 Vue 3，订单、支付、分销和操作记录放在 MySQL。配置不写进代码，Docker 和 Nginx 部署。助手如果超时，只把已经确认的信息留下来，并说明这张单有没有生成。