团购核销：券码验真，核销对账不糊涂

团购核销，麻烦的从来不是"核一下"

做本地生活生意的商家，几乎都有过这么一段：在团购平台上架了一个套餐，单子哗哗地来，门店却开始乱。

• 券是真的还是截图？ 店员看一眼顾客手机上那张券图，心里没底。有人用截图、有人用别人转发来的券码，吃过一次亏之后就只能靠"这单我不认"硬扛，顾客体验很难看。
• 同一张券核了两次。 门店多、店员轮班、换班没交接，同一张券在两台手机上各核了一次，月底平台结算时才发现，钱已经付出去了。
• 活动结束了才知道亏。 哪个门店核销率最高、哪张券发出去没人用、哪个套餐核了以后顾客再也不来——这些答案散在平台后台和门店微信群里，等活动结束才想起来复盘，已经晚了。
• 对账要一个月。 平台给的结算单是一行行汇总数，门店报的是自己记的本子。两边差几百块，要一条条回查是哪一单，翻聊天记录、翻小票，常常拖到次月还查不清。

这些问题的共同点很清楚：券从发出去到核掉的过程，没有沉淀在自己手里的一本账上。平台后台只负责发券和结算，门店负责核销现场，中间的"谁在什么时候核了哪张券、为什么这一单有争议"没人记。本文讲的就是怎么用 Inkwell AI 构建器把这个中间段补上：把活动、门店、券码、核销流水四本账建起来，再用页面和手机端把它们变成一个能天天用的核销台，最后让核销流水能和平台结算单对上。

先说清楚边界：这套模块负责"核销现场与核对"，不负责在团购平台上发券、不做平台侧的资金结算。券码由活动平台生成或导出，系统负责导入、验真、核销、留痕、对账。

第一步：四张底表，先把关系理顺

搭这类模块最容易犯的错，是想一张表解决所有事——一个"团购券"表塞进活动信息、门店信息、核销时间、核销人，用起来还行，一旦要按活动统计、按门店对账就开始难受。正确的做法是先分清四件事，它们的关系是固定的：

1. 活动表（一次团购活动一行）

• 活动名称、来源平台、活动起止时间、活动状态（筹备 / 进行中 / 已结束 / 已下架）
• 券面内容：是代金券还是套餐券、面值或套餐明细
• 使用规则：每桌/每单限用张数、法定节假日是否可用、是否限堂食、是否可与其他优惠同享
• 单据性质的东西（活动变更、提前下架）建议走平台的审批流，改规则这件事有人签字才动手

2. 门店表（一家门店一行）

• 门店编码、门店名称、所属区域、营业时间、负责人
• 门店编码一定要设成唯一并且全公司统一口径（不要这家写"001店"、那家写"一店"），后面所有对账都靠它把平台数据、核销流水、门店报表串起来
• 门店与活动的参与关系单独建一张关联表（哪家门店参加哪场活动、该店分配券量），不要塞进活动表的"适用门店"一个文本字段里——一旦活动做到第三场、门店过十家，文本字段就没法统计也没法控制权限

3. 券码表（一张券一行，这是整套系统的核心底账）

• 券码（设为唯一）、所属活动、所属门店或通用、券面内容、有效期
• 状态：未使用 / 已核销 / 已退款 / 已过期 / 已作废
• 导入批次号与导入人（出问题能一把撤回或定位到某一批）
• 绑定信息：顾客手机号后四位或订单号（按你们的合规口径，能少存就少存）

这里有一个关键设计决定：券码唯一约束必须在数据库层做，不能只靠页面校验。 券码重复是这类系统最常见的脏数据来源——同一批文件导了两次、两个运营同时导入、平台导出的表里本来就有重复行。唯一约束让系统直接拒绝第二条，而不是等核销时才发现两张一样的券。

4. 核销流水表（每核一次一行，只增不改）

• 核销时间、核销门店、核销操作人、引用的券码
• 本单补充信息：到店人数、关联消费单号（如有）、备注
• 凭证：现场照片（如团购套餐上菜图、争议现场图）通过平台的文件模块上传挂在这条流水上
• 流水状态：正常 / 争议 / 已冲正

关键决定之二：券码和核销流水要拆成两张表，用"引用"关系连起来。 券码只记录"这张券现在是什么状态"，核销流水记录"曾经发生过什么"。如果把核销信息直接写在券码行上，冲正一次、补录一次，历史就被覆盖了，对账时你说不清到底是哪天核的。

两个能让后期省很多事的平台能力，值得在建模阶段就用上：

• 数据字典统一选项口径：券状态、活动状态、券类型、争议原因这些"选来选去就那几项"的字段，用平台的数据字典集中维护。以后加一个"部分核销"的状态，改一处、所有页面和报表同步生效，不会出现同一个状态在三个模块里三种写法。具体做法见 数据字典：管好下拉选项的统一口径。
• 跨模块引用：核销流水引用券码、引用门店，用平台的引用引擎（一种软外键机制，让一个模块直接取另一个模块的档案作为选项，不必把门店名再抄一遍）接起来。门店改名，历史流水里显示的也是最新名称，不用回头批量改。

券码怎么进来？绝大多数团购平台的券码可以导出成 Excel。用平台的 Excel 导入把表头和字段对齐一次，之后每场活动传一个文件就行，具体流程见 用 Excel 一步建模块。导入前务必先做一次去重校验——让系统在导入时报出"文件内重复"与"库里已存在"两类冲突，而不是先导进去再清理。## 第二步：按角色配页面，四个人看到的不是同一张表

数据建好只是地基。核销这件事每天要发生几十上百次，页面必须是"每一类人打开就知道该点哪"的样子。建议按四个角色分别做视图，而不是给所有人一个全字段的大表。

运营：活动台账与券码管理

• 活动列表页：进行中的活动排在最前，带已发券数、已核销数、核销率三个关键数（核销率由券码状态统计得来，不需要手工填）
• 活动详情页：上半部分是活动与规则，下半部分挂券码子表——这场活动发了多少张、核掉多少、剩余多少、作废多少，一屏看完
• 券码导入页：上传文件、预览前 20 行、确认导入；导入结果要明确给出"成功 N 条 / 文件内重复 N 条 / 库中已存在 N 条 / 格式错误 N 条"，出错的明细可下载回去修
• 券码查询页：按券码、门店、状态、有效期区间筛，用于客服接电话时三秒找到这一单

门店店员：核销台（以手机端为主）

这是全系统使用频率最高的页面，设计原则是"少输、少想、有反馈"：

• 输入券码 → 系统即时返回这张券的券面内容、有效期、是否可用（节假日限制、限用张数）、当前状态，四个信息在一屏内给全，店员不用切页面判断
• 状态是"已核销"的，页面直接标红并显示上一次核销的时间、门店、操作人——重复核销在这里被挡住，而不是事后发现
• 确认核销时填到店人数、可传照片，一次提交；提交后立刻给出"核销成功"与本次流水号
• 当天本店核销记录列表：店员自己随时能回看今天核过哪些单，交接班时对着手机数一遍即可

店长：本店核销与异常处理

• 本店核销流水页：按日期、券种、店员筛，能看到核销笔数与对应活动
• 异常/争议流水页：被标为争议的单子集中在这里，店长填处理意见，需要冲正的提交审批
• 本店参与的活动与该店额度：避免门店之间互相"借券"

财务：对账页（这套系统真正的价值出口）

• 平台结算单导入：把每期平台给的结算明细导进来（这一步同样用 Excel 导入），得到"平台认为核销了多少单、结算多少钱"
• 对账比对页：以门店编码 + 日期 + 券码为比对键，自动分成三类——两边都有（匹配）、只有我方有（可能平台未结）、只有平台有（可能我方漏核或跨店核销）
• 每一类都可下钻到具体券码与流水，差异不再是几百块一个数字，而是一条条可指认的单子
• 差异处理有结论：确认漏核的补录、确认无效的标争议，处理完这一期的对账结果留档

第三步：把重复动作交给规则，而不是靠人记得

核销这件事有大量"到点该做、但没人会主动做"的动作，正好交给平台的三类自动化：

数据流规则（条件触发的数据变换）

• 核销流水新增 → 自动把对应券码状态改为"已核销"、回写核销时间与门店。让"改状态"不再依赖页面上的第二次操作，杜绝"流水有了、券还是未使用"的错位
• 券码状态改为"已核销" → 在该券所属活动的核销计数上累加，看板的核销率不再靠人工统计
• 核销金额或人数超过阈值、或同一门店短时间内高频核销 → 打上标记并通知店长复核。高频核销是刷单和内部作弊的典型特征，让规则先看见

定时任务（按 Cron 配置自动跑）

• 每天凌晨扫一遍券码表，把过期未用的置为"已过期"——这个动作影响核销率的准确性，不能靠人一天天点
• 每周一早上推送上一周各活动、各门店核销汇总，运营打开就是结论
• 每期结算单导入后自动跑一次对账比对，把差异条数推给财务——从"月底集中算一次"变成"每期自动报警"
• 券即将到期（比如到期前三天）提醒活动负责人，该做二次触达还是准备下架，时间还来得及

审批流（谁在什么条件下能改什么）

• 超时补录（顾客当天未核、次日找回）：必经店长审批
• 跨店核销：其他门店的券在本店核，走审批并留原因
• 冲正/作废已核销流水：金额敏感动作，二级审批

配置方式见 工作流与定时任务：让重复性工作自动跑 与 审批流落地：请假、报销与通用申请怎么在线化。

再加上审计日志兜底。 谁改过券码状态、谁冲正过流水、谁导出过券码全表，平台的审计日志都有留痕，可将敏感操作（如批量导出、改状态）纳入重点监控。见 AI 监控与审计日志。

权限上，按"门店只看本店"来切：门店店员的角色只授予本店核销流水的查看与新增，看不到别店数据、看不到券码全表；运营看活动与券码；财务看流水与对账。这块参考 角色与权限配置：从内置角色到自定义授权。## 第四步：移动端是核销的主战场

核销发生在收银台和餐桌边，店员手里只有手机——所以这套模块的 PC 端是给运营和财务用的，手机端才是门店每天真正在用的那一半。用 Inkwell AI 构建器搭的模块发布后会自动同步出移动端页面，不需要再单独做一遍，具体机制见 PC 构建的模块，如何自动出现在手机上 与 移动端使用指南。

移动端要专门调的三件事：

1. 核销台放在工作台第一屏。 店员一天开几十次，路径越长越容易被绕过（绕过就意味着记在本子上，账又散了）。
2. 信息大字呈现。 券面内容（套餐含什么）、有效期、可用张数要一眼看清，别让店员在小字里找"节假日不可用"这句话。
3. 现场凭证随手拍。 争议单、加菜、特殊处理，直接用手机拍照上传挂到流水上，照片存在平台的附件里跟着单子走，不散在微信相册。

关于"扫码"这件事要说清楚：本模块保证的是券码的唯一性与实时状态校验——不管券码是手动输入、粘贴还是由外部设备读入，判断"真不真、用过没用"都由系统来做。如果希望在门店用摄像头直接识别顾客手机上的券码图，那属于前端设备与浏览器的识别能力，需要在实施时按门店实际设备确认，不属于本模块自带承诺的能力。折中而可靠的做法是：店员粘贴券码 + 系统实时校验 + 大字号结果回显，速度并不比扫码慢多少，且不依赖设备。

第五步：上线前，逐条查这七件事

1. 券码历史数据先清洗。 老活动的券码要不要一起迁进来？只迁未使用的还是全量？迁之前先去重、先把格式统一（有的平台带字母前缀，有的纯数字），否则唯一约束会让导入大量报错。
2. 状态字典定稿。 未使用 / 已核销 / 已退款 / 已过期 / 已作废，五个状态够不够？有没有"部分核销"？字典定的越早，后面改的代价越小。
3. 门店编码与平台口径对齐。 平台结算单里的门店名，和你的门店表编码能不能一一对上？对不上就先建一张映射，别指望每次人工核。
4. 权限按门店切。 上线前确认门店角色真的看不到别店数据和券码全表——这条一旦漏掉，等于把全部门店的券码摊在所有人面前。
5. 对账口径写成对照表。 平台结算单的哪一列，对应核销流水的哪个字段？用金额、笔数还是券码？比对键定不下来，系统再准也吵不明白。
6. 营业日怎么切。 凌晨 0 点后核的券算前一天还是后一天？夜宵门店、酒吧这类场景必须先定，否则每天都有几笔在对账时来回跳。
7. 一家门店先跑真券。 拿一场已上线的活动，在一家门店真实核销一周，专门看三件事：有没有重复核销被挡住、有没有跨店单出现、对账差异能不能在十分钟内指认到具体券码。

最后走一遍平台的发布预检，确认模块挂到了菜单、移动端页面同步生成、权限与数据都正常，再全门店推开。流程见 模块的测试与发布。

上线之后能往哪延伸

这套四表结构是底座，往上加东西不难：

• 多平台统一。 抖音、美团、小红书来的券，只要字段能对齐，都进同一张券码表，用"来源平台"字段区分——运营只管一个后台，不用五个平台反复切
• 与会员打通。 核销时挂到会员档案上，谁在用团购券、核了之后有没有复购，能看得到。见 零售门店会员管理
• 与库存/进销存联动。 套餐核销后按 BOM 自动扣减原料或商品库存（套餐卖了多少份，原料就备多少）。见 零售门店进销存
• 门店督导与排行。 按区域、按活动排名核销率与核销量，把"哪家店在推、哪家店在敷衍"变成一张可看的分区表
• 顾客侧查询页。 做一个只读的查券页（用参数带入券码），顾客自助看有效期与可用门店，减少一半咨询电话

什么情况下不要做这套

诚实说清边界，比承诺什么都能做更有用：

• 只有一两家门店、一个月几十单：直接在平台后台核销、月底看平台结算单就够了，建一套系统的运维成本高于收益。
• 把券码生成、发券、资金结算也交给这套模块：不合适。这些属于活动平台的责任范围，本模块记录与核对，不替代平台。
• 指望它自动反刷单：可以做的是规则预警（高频核销、异常时段、异常门店）加人工复核，做不到了解全部作弊手法，别把风控责任交给一个表单。
• 券码规则极其复杂的场景（叠加优惠、阶梯折扣、跨品牌通用）：先评估规则能不能用字典 + 数据流规则表达清楚，表达不清的部分仍应由平台侧承担。

一句话记法：活动给券，系统管账；门店核销，财务对账。 把中间这一段落成一本自己手里能查的账，团购这件事就从"心里没底"变成了"数得清"。