零售门店会员管理：档案、储值消费与积分一本账

门店会员档案、储值账户与充值消费流水、积分规则怎么用 AI 构建器落地：四张表定边界、开卡到充值的页面链路、移动端店员操作与上线前的余额口径核对。

门店会员的账，为什么总是对不上

做零售的老板大多遇到过这样几件事：

顾客拿着储值卡来消费，收银员翻不出他上次充了多少、还剩多少，只能靠一张卡或一本手写台账；
储值卡充值和赠送的额度混在一起，月底对账发现"卡里余额加起来"和"实际收到的钱"对不上，差额谁也说不清；
积分规则是口头的，消费多少积多少分、多少分抵多少钱，门店之间说法不一样，顾客一投诉就变成了人情处理；
想看看有多少老客户三个月没来了，得靠店长凭印象报名字。

这些问题的根子不在于"缺一个会员系统"，而在于三件事没有分开：档案、账户、流水。

会员档案回答"这个人是谁、在哪家店开的卡、什么等级"；储值账户回答"他现在账上还有多少钱、多少积分"；流水回答"这些钱和分是怎么一笔一笔变成现在这个数的"。很多门店把三者压在一张 Excel 表里，于是余额永远是个"填"出来的数，而不是"算"出来的数——一旦对不上，就再也回不到原始记录。

用 Inkwell Engine（AI 构建器）做一个会员与储值模块，思路就是先把这三件事拆开，再用页面把它们重新连起来。整个模块的业务数据、管理页面、状态流转和手机端伴同都是构建器可交付的范围，不需要另找一套供应商系统对接。

数据怎么建：四张表定边界

在构建器里描述需求时，把表结构讲清楚比讲功能更有用。建议至少分四层数据：

一、会员档案（主表）

一位会员一条记录，字段大致是：会员编号（系统自动生成，同时也是对外可报的卡号）、姓名、手机号、性别、生日、开卡门店、开卡日期、会员等级、来源渠道、状态、备注。

两个约定要在建表时说死：

手机号作为业务唯一键。同一个人在同一家连锁里只能有一个会员身份，否则储值余额会分裂成两笔，对账时无法合并。构建器支持字段唯一性校验，把手机号设成唯一，重复开卡时直接报错，比事后合并数据省事得多。
状态只保留有限几个值：正常、挂失、停用。状态之间的流转（补卡、解挂、注销）单独留痕，不要用"改一下状态字段"糊过去。

二、储值账户（主表，与会员一对一）

这张表只存"当前余额"，不存过程：卡号、卡类型（储值卡、次卡等）、账户余额、赠送余额、累计充值、累计消费、积分余额、积分有效期、状态。

金额字段按平台的字段约定用分（整数）存储，页面上再按元展示。小数点浮点数做钱的加减，迟早会差几分钱，那是财务上最不想解释的差异。卡类型、账户状态这类下拉选项，交给数据字典统一维护——门店、等级、卡类型、流水类型全部集中在一个字典里管理，避免每张页面各写一套选项，将来改口径只改一处。

三、储值流水（明细表）

每一次余额变动生成一条不可修改的流水：流水号、会员、卡号、类型（充值、消费、退款、赠送、期初、人工调整）、变动金额、变动后余额、支付方式、关联单据号、发生门店、操作人、发生时间、备注。

这张表是整个模块的"账本底稿"。账户余额永远等于该会员所有流水变动金额的累计——只要坚持这条等式，余额就不再是"填"的，而是随时可重算、可核对的。任何人工修改余额的动作，都要走一条"人工调整"类型的流水，写清原因，而不是直接改账户表。

四、积分流水与积分规则

积分和储值分开记：积分流水记录变动类型（消费得积分、兑换扣积分、人工调整）、分值、变动后积分、有效期。积分规则则是一张小的配置表或者一组字典项：多少金额对应多少积分、兑换比例是多少、积分是否随月份清零。

这里有一条数据边界必须提前想清楚：会员模块不重复存商品销售明细。消费登记时，会员模块只记"哪位会员、在哪个门店、关联哪张销售单、金额多少"，商品明细留在销售模块里，用关联单据号引用过去。如果两处都存商品行，改一次价、退一次货就要同步两个地方，迟早不一致。

销售单与会员之间的关联用平台提供的引用机制（软外键：只记对方的编号，不建数据库级别的强关联），这样会员模块可以独立发布、独立改字段，不会被销售模块的结构变化拖着走。## 页面怎么用：从开卡到充值消费的一条线

数据建好之后，页面只要围绕一条主线排布就行：找到人 → 看账 → 办业务 → 留痕。

会员列表页是日常入口。顶部搜索框支持手机号、姓名、卡号三种查法——顾客站在前台报手机号是最常见的场景，所以手机号搜索必须是第一位的。筛选条件放等级、开卡门店、状态；列表列展示会员号、姓名、手机号、等级、账户余额、积分余额、最近消费日期。列表右侧挂三个高频操作：查看、充值、挂失。

会员详情页是把四张表拼回一个视角的地方。上半区是档案信息与账户卡片（余额、赠送余额、累计充值、累计消费、积分），下半区用页签排三条明细：储值流水、积分流水、消费记录。这样收银员遇到"我上次充了多少"这种问题，点开一个页面就能回答，不用去翻别的表。有了疑义，还能直接对着流水一行行解释。

开卡与充值表单是最需要防错的页面，三条规则务必在构建时就写进校验里：

开卡时手机号必填且唯一，重复时给出"该手机号已有会员，是否直接为他充值"的提示，而不是抛一个技术错误；
充值金额、赠送金额必须为正数，赠送额度只进"赠送余额"，不混进实收金额——这两笔钱的财务性质不同；
提交成功后，页面同时写入一条流水并回写账户余额，两者要么一起成功，要么一起失败。

第三条是本模块能不能长期用下去的关键。余额和流水由同一次提交产生，中间没有"人工再点一步"的环节，可以最大限度避免"有流水没余额"这类脏数据。

等级与积分规则页是店长或运营维护口径的地方。等级门槛（累计消费到多少升一级）、积分获取与兑换比例、积分有效期都做成配置项，改口径不需要找开发改代码。想让等级随累计消费自动调整，可以用数据流规则（按条件自动触发的一段数据处理）在消费登记之后重算等级，或者用定时任务每天夜里统一扫一遍，把符合条件的会员批量升级。前者实时、后者简单，看门店对时效的要求选。

储值统计看板回答老板的问题，建议至少三个视图：按门店看今日与本月充值额、消费额、余额沉淀；按等级看会员数与消费贡献；按月份看充值趋势。储值余额沉淀是一个容易被忽略但很关键的指标——它是门店的一笔负债，得随时看得到总数。

提醒类任务交给定时任务加通知：会员生日前一天推一条提醒给门店，积分即将到期前推给会员，三个月未消费的会员列进"沉睡名单"交给店长认领。这类活儿靠人记一定会漏，交给系统每天固定时间跑一次最省心。

移动端：店长和店员在手机上要做的三件事

会员模块的移动端不需要把 PC 页面照搬一遍，抓住三个真实场景就够：

一是店员在收银台旁给顾客充值。 顾客报了手机号，店员在手机上搜出会员、看清当前余额、录入金额提交，一条流水就落下来了。表单字段和 PC 端完全一致，校验规则也一样——移动端和 PC 端共用同一个模块的后端与数据，不是两套系统。

二是店长随时看本店的储值与会员数据。 今日充值多少、本月新增多少会员、有多少余额沉淀，用手机上的统计视图看一眼就行，不用特地跑回门店开电脑。

三是会员查询与提醒处理。 前台被问到"我卡里还有多少"，手机一搜就能答；生日提醒、沉睡名单直接在手机上处理掉，形成闭环。

构建器生成模块时，PC 页面建好之后会同步出现在手机工作台上，页面按屏幕宽度自适应，需要单独优化的地方再针对移动端调整。也就是说，会员模块的移动端不用重新做一遍开发，是同一份业务的另一个入口。

权限上，手机端尤其要收紧：门店店员的可见范围应限定在本店会员，跨店余额查询与人工调整余额这类敏感操作，只留给店长或财务角色，并且每一次人工调整都要在操作日志里留痕。## 上线前检查：余额口径、去重、权限、隐私

模块做完不等于能上线。会员与储值涉及钱和个人信息，上线前建议按下面几项逐条过：

一、历史数据怎么进。 老门店一定有一批会员和余额在 Excel 里。用平台的导入能力把这些表格一步做成模块的数据入口是常见做法，但导入会员前必须先做两件事：手机号去重，同一个号码只保留一条；期初余额单独一条流水。第二件事尤其重要——导入时不要直接把余额写进账户表，而是为每位会员生成一条"期初"类型的流水，金额等于导入余额。这样"账户余额 = 流水累计"这条等式从第一天就成立，后面任何一次对账都有完整依据。

二、权限和数据范围。 谁看得到哪些会员，上线前要定下来。店员默认只看本店会员、只能做开卡和消费登记；充值赠送额度、人工调整余额、批量导出这三类操作收给店长或财务角色。角色与权限在平台里是现成能力，按岗位配好即可，不需要另写规则。

三、个人信息与留痕。 手机号、生日属于个人信息，字段级别的可见范围应当收紧，导出这类动作要有记录，方便追溯是谁、什么时候导了什么。平台的审计日志会把这些敏感操作留痕，上线前把"哪些操作要留痕"列清楚。

四、几条容易漏的业务规则。 挂失状态下能不能消费？余额能否跨店通用？退款是退到储值余额还是退回现金？这些不是技术问题，而是口径问题，但必须在配置里写死，否则不同门店会各做一套。如果退款或余额调整需要主管签字，就挂上工作流审批——提交后按节点流转，审批通过再回写账户，流程运转本身有记录。

五、先小范围跑，再全量铺。 构建器支持在沙箱里试跑模块，发布前会做预检，把配置或数据上的问题拦在前面。建议选一到两家门店先试运行一段时间，重点看三件事：开卡是否顺畅、充值后余额与流水是否始终一致、统计看板上的数字与门店手里的小账本是否对得上。对得上再往全部门店铺开，并顺手把菜单挂到对应角色的工作台上。