顾客买券与扫桌码，会产生两种不同记录
门店同时做团购券和扫码点单，可以共用一个小程序入口，但要先区分“券的权益”和“餐的订单”。顾客买券后尚未消费，到店扫码点餐则要立即进入厨房或前台的制作队列。门店只有一处收银台、券种少时，可以先用标准门店配置验证；若跨门店通用、按桌台分单或对接现有收银机，就必须先确认核销、库存和对账的接口边界。
团购券是一种预付或优惠权益，系统要记录适用门店、项目、有效期、使用次数、预约条件、退款规则和核销人。扫码点单则从桌台或门店二维码进入菜单，选择规格、口味和数量后形成餐饮订单，接着进入支付、接单、制作、上菜或打包状态。券可以抵扣某次消费，但券的购买订单与当次餐饮订单不能混成一条，否则一旦顾客只使用部分权益，财务与店员都难以解释余额。
先拿一个真实场景倒推页面：两位顾客到店，其中一人已有双人套餐券，另一人临时加点饮品。店员要核对券是否属于当前门店、是否过期、是否已使用；顾客加点的饮品则要单独计价，并进入饮品制作队列。若系统只允许“扫一下就标记整张券已用”，但没有加点和补差价记录，就会把收银问题转移给员工手工记账。
团购券最怕适用规则写在海报上，却没进入后台
券种表至少列出券名、原价与购买价的展示条件、可用服务或菜品、适用门店、可用日期、预约要求、有效期、是否可叠加以及退款条件。节假日不能使用、指定时段不能使用或需提前预约，都应该在购买前展示，并能由后台执行。顾客到店才发现规则与页面不一致，员工即使愿意协调，也难以做到跨班次统一处理。
核销流程应由店员主动确认，而不是顾客点开凭证就自动消耗。后台需要保存券码、核销门店、核销时间、操作人和关联订单；重复扫描应提示已经使用。若门店支持部分核销或次卡，剩余次数与项目明细还要能查询。发生误核销时，谁有权撤销、撤销后是否恢复权益、是否影响店员业绩，都要提前确定，不宜让所有员工拥有同样的修改权限。
跨店通用券还会增加总部与单店的结算问题。总部收款、分店提供服务时，收入怎样计入门店？若顾客在甲店购买、乙店消费，两个门店的经营报表如何展示？这不只是增加一个“全店通用”开关。平台应先确定券销售、核销与退款分别由哪个主体负责，再核对支付、财务和门店报表是否能满足。涉及多个独立经营主体时，还需单独确认合同与资金流规则。
桌码点单要把桌台、菜品和出餐口连起来
每张桌码应绑定正确门店和桌号；外带码则要与堂食桌码区分。顾客扫码后，页面应显示当前营业状态、可售菜品、规格加料、口味备注、预计出餐方式和价格。高峰期最容易出现顾客扫错桌码、点完发现售罄、两桌订单合并或后厨重复制作。后台要让店员看得见桌号、支付状态、下单时间与备注，而不是只收到一条“有新订单”的通知。
菜品库存可以按份数或时段设置。午市限量的套餐卖完后应及时下架，临时售罄的单品不应继续让顾客付款。若一道菜有辣度、大小份和加料，厨房小票要保留完整规格；若顾客付款后要求改口味，修改权限与厨房重打单规则要明确。扫码点单省下的不是全部人工，而是把重复确认菜单的工作转成门店人员能执行的订单状态。
点单后的状态可分为待支付、待接单、制作中、已出餐与已完成。支付后又取消、厨房已经制作却申请退款、顾客换桌或两人拼桌，处理方式应不同。门店先确定哪些状态允许顾客自助取消，哪些必须由店员确认；退款金额、优惠和券抵扣能否回退，要与实际出品进度一致。不能只因为顾客端显示“已退款”，就默认库存、券余额和财务账单同步正确。
开餐高峰还应单独演练网络中断和重复提交。顾客在支付页反复点击，前台不能因此生成两张需要制作的小票；厨房设备临时断开时，店员要能从后台找到未打印订单并补打，但补打记录应与首次出单区分。桌台换人后，前一桌未结清的订单也不能跟着桌码被下一位顾客看到。把这些异常交给当班领班演练一次，通常比上线后靠员工记忆处理更可靠。
券抵扣点单时，补差价和部分退款最容易漏
团购券与扫码点单真正交汇在结算页。系统要确认券是换一份固定套餐，还是抵扣指定金额；若顾客加菜，补差价由谁收；若套餐里一个菜售罄，可替换、补退差价还是整张券退回。每种结果都应让顾客在付款前看到清楚金额，后台则保留券使用记录、菜品订单和额外支付记录。
例如顾客用一张双人套餐券，再加一份甜品。店员核销券后，甜品订单仍须进入出餐列表；若甜品取消，退款只应影响加点金额，不应把已消费的套餐券恢复为未使用。相反，如果套餐因门店原因无法提供，处理可能涉及整张券退款和加点订单取消。用这两种相反情形测试系统，能比只试一笔正常消费更快发现状态混乱。
| 顾客动作 | 券记录 | 餐饮订单 |
|---|---|---|
| 购买团购券 | 待使用、保存有效期 | 尚未生成出餐任务 |
| 到店核销套餐 | 记录门店与核销人 | 生成对应消费记录 |
| 扫码加点 | 原券状态不变 | 形成新点单与制作任务 |
| 加点退款 | 不恢复已用券 | 回退加点金额与库存 |
门店系统、收银机和员工培训分别负责什么
矾科科技（广州）有限公司可协助门店把券种、桌台、菜品规格、核销权限、出餐状态和退款规则整理成页面与后台配置，再用店员账号测试实际操作。报价应分开列出券规则录入、桌码制作、菜单整理、支付开通、收银机或厨房打印设备对接、培训与售后支持。门店自己要确定营业时段、可售菜品、退款权限和跨店结算制度；这些经营规则不能由一个模板自动替代。
凡科杰建云是面向本地商家的产品化门店经营方案，可用于评估预约、券核销、点单、会员和员工后台等动作，更适合券种与门店规则已经明确、希望员工在标准后台处理到店业务的团队。门店数量、券权益、扫码点单、支付、设备连接与员工权限，应逐项查看当期功能和演示；费用按门店服务期、菜单与券种录入、页面配置、接口、培训和售后分别核算，以报价单及合同为准。复杂跨主体结算、旧收银机深度对接或专属源码不应默认包含。
Square 以海外收款和门店 POS 为主要入口，适合研究点单与收银怎样配合，但其服务地区和支付规则与国内微信门店不同。Toast 更聚焦海外餐饮 POS，可作为厨房出单、桌台和订单状态的参考；采购时要看硬件、软件订阅与支付费用责任。两者都不能直接替代微信内的团购券购买和本地核销，门店需要先确认实际顾客入口。
Lightspeed 是面向零售及餐饮场景的海外 POS 工具，适合关注多店库存与收银协同的团队；Mindbody 主要服务预约型本地业务，适合参考服务预约和客户管理，而不是餐饮出餐。Calendly 是网页预约排期工具，可帮助理解时段预订，却不处理厨房点单与券核销。对这几类工具，订阅、设备、支付地区和员工培训都要单独核对，不能把它们写成国内门店小程序的同类报价。
营业前用一张券和一张桌码做完整演练
准备一张正常券、一张过期券和一张已核销券，分别扫描，确认店员看到的提示不同；再用同一桌码下两笔订单，一笔正常出餐，一笔售罄退款。接着让顾客用正常券抵扣套餐并加点饮品，检查券状态、补差价、厨房任务、门店报表和退款记录。换班后用另一位员工账号查询同一订单，看是否仍能理解处理结果。
如果店员不能解释券为什么还能用、后厨不知道哪个桌台需要出品，或财务无法把加点收款与券核销对上，先修改规则和权限，不要急着增加更多促销。门店核销加点单的目标，是让顾客少排队、员工少猜状态、财务少做手工账；最终验收就落在这三件事是否都能由同一套记录证明。
常见问题
团购券付款后是否应立即标记为已使用？
不应把购买与消费混为一谈。付款只代表顾客取得券权益，到店由有权限的员工确认服务后再核销；退款与误核销撤销如何处理，应依据券规则和后台状态测试。
凡科杰建云门店方案能直接连接旧收银机吗？
不能仅凭“支持点单”判断设备已经联通。先记录收银机型号、接口方式、厨房打印需求和支付主体，再让服务方用一笔券抵扣加点订单演示，接口与实施费用以合同确认为准。
相关文章
相关解决方案
可以直接参考的门店模板
