首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >青海社区团购小程序:开团模型、自提点库存与团长体系的工程实现

青海社区团购小程序:开团模型、自提点库存与团长体系的工程实现

原创
作者头像
用户3066938
发布于 2026-10-24 12:25:30
发布于 2026-10-24 12:25:30
310
举报

社区团购在下沉市场持续运转的核心是三件事:开团节奏、自提点履约、团长分佣。它的技术复杂度不在流量峰值——团购是计划性购买,流量是可预期的——而在订单归集与履约单据的转换链路:用户订单怎么归集成向供应商的采购单,采购单怎么拆成每个自提点的分拣单。本文给出可落地的模型,基于 MySQL 8 + Redis,部署可用云托管。

一、核心对象:团次是一等公民

社区团购不是"随时下单",而是"某个团长在某段时间开的某次团"。所有交易围绕团次(group_buy)展开:

代码语言:txt
复制
CREATE TABLE leader (
 id           BIGINT PRIMARY KEY AUTO_INCREMENT,
 name         VARCHAR(30) NOT NULL,
 phone        CHAR(64) NOT NULL COMMENT '加密存储',
 station_id   BIGINT NOT NULL COMMENT '绑定自提点',
 commission_rate INT NOT NULL DEFAULT 800 COMMENT '佣金比例,万分比',
 status       TINYINT NOT NULL DEFAULT 1,
 UNIQUE KEY uk_station_phone (station_id, phone)
);

CREATE TABLE station (
 id          BIGINT PRIMARY KEY AUTO_INCREMENT,
 name        VARCHAR(60) NOT NULL,
 addr        VARCHAR(200) NOT NULL,
 lat DECIMAL(10,6), lng DECIMAL(10,6),
 capacity    INT NOT NULL DEFAULT 200 COMMENT '日均自提承载',
 status      TINYINT NOT NULL DEFAULT 1
);

CREATE TABLE group_buy (
 id           BIGINT PRIMARY KEY AUTO_INCREMENT,
 leader_id    BIGINT NOT NULL,
 title        VARCHAR(80) NOT NULL,
 start_at     DATETIME NOT NULL,
 end_at       DATETIME NOT NULL,
 delivery_at  DATE NOT NULL COMMENT '预计到货日',
 status       TINYINT NOT NULL DEFAULT 1
 COMMENT '1开团中 2已截团 3已到货 4自提中 5已结束 6已取消',
 KEY idx_leader (leader_id, start_at)
);

CREATE TABLE gb_sku (
 id           BIGINT PRIMARY KEY AUTO_INCREMENT,
 group_id     BIGINT NOT NULL,
 sku_name     VARCHAR(80) NOT NULL,
 spec         VARCHAR(60) NULL,
 price        INT NOT NULL COMMENT '团购价,单位分',
 stock        INT NOT NULL DEFAULT 0 COMMENT '本次团限量',
 sold         INT NOT NULL DEFAULT 0,
 sort         INT NOT NULL DEFAULT 0,
 KEY idx_group (group_id, sort)
);

设计要点:团次到截团时间是硬边界。截团后订单锁定、进入采购,SKU 不可再改;用户下单在 end_at 之前,用服务端时间校验,别信客户端。gb_sku.stock 用条件更新防超卖(WHERE stock - sold >= qty),团购限量是刻意的稀缺运营,超卖会直接打脸运营策略。

二、订单与佣金:两层账要分开

用户订单和团长佣金是两个账本,混在一起必然出错:

代码语言:txt
复制
CREATE TABLE gb_order (
 id           BIGINT PRIMARY KEY AUTO_INCREMENT,
 order_no     VARCHAR(32) NOT NULL,
 group_id     BIGINT NOT NULL,
 leader_id    BIGINT NOT NULL,
 user_id      BIGINT NOT NULL,
 total        INT NOT NULL,
 commission   INT NOT NULL COMMENT '本单佣金,下单时锁定',
 status       TINYINT NOT NULL DEFAULT 1
 COMMENT '1已支付 2截团 3已到货 4已自提 5售后中 6已退款',
 picked_at    DATETIME NULL,
 UNIQUE KEY uk_no (order_no),
 KEY idx_group_status (group_id, status),
 KEY idx_leader (leader_id, status)
);

佣金在下单时按当期比例锁定,而不是结算时再算——团长改级别、活动期比例变化,都不影响历史订单。佣金入账条件是订单走到"已自提"(用户提走),退款单要同步冲减佣金。账目规则一句话:商品的钱跟订单走,佣金的钱跟履约走。

三、截团后的单据转换:这是团购系统真正的骨架

截团那一刻,系统要把几千笔用户订单转换成三种单据:

代码语言:txt
复制
async function closeGroup(groupId) {
 const orders = await db.query(
 `SELECT * FROM gb_order WHERE group_id = ? AND status = 1`, [groupId]);

 // 1. 汇总为采购单:按 SKU 聚合
 const purchase = groupBy(orders.map(o => o.items))
 .map(([skuId, qty]) => ({ skuId, qty: sum(qty) }));

 // 2. 拆分为自提点分拣单:按 leader 归组
 const picking = groupBy(orders, o => o.leader_id)
 .map(([leaderId, os]) => ({
 leaderId,
 lines: groupBy(os.map(o => o.items))  // 每个自提点的拣货明细
 }));

 // 3. 生成售后责任快照:每个 SKU 在截团时的供应商
 // (供应商换批次后,售后归属要按截团时点判断)
 await savePurchaseSheet(groupId, purchase);
 await savePickingSheets(groupId, picking);
}

三种单据的用途:采购单给供应商,按 SKU 汇总数量;分拣单给每个自提点,到货后按单分货;售后快照记录截团时的采购归属,因为生鲜售后常在到货两三天后才发生,那时供应商可能已经换了批次,没有快照就说不清责任。

分拣单打印格式值得花心思:团长不是仓库管理员,单据要按"谁订的什么、几份、电话尾号"排,到货时团长按单喊人取货。这是打印模板的问题,不是架构问题,但直接影响履约效率。

四、到货与自提:状态推进靠扫描而不是手点

到货后,货从供应商到自提点,用户来提。状态推进的准确率决定体验:

- 到货登记:团长在小程序端确认"本团已到货",缺货 SKU 单独登记,触发该 SKU 订单的自动退款流程;- 自提核销:用户出示取货码,团长扫码核销,订单置为已自提、佣金入账;- 超时未取:到货 N 天未取的订单提醒用户,再超时按规则处理(生鲜类通常电话催提后销毁,损耗记账)。

缺货处理要单独建模。生鲜团购缺货是常态,缺一个 SKU 不能整单退款,要按行退款:

代码语言:txt
复制
CREATE TABLE gb_refund_item (
 id          BIGINT PRIMARY KEY AUTO_INCREMENT,
 order_id    BIGINT NOT NULL,
 sku_id      BIGINT NOT NULL,
 qty         INT NOT NULL,
 amount      INT NOT NULL,
 reason      VARCHAR(100) NOT NULL COMMENT '缺货/质量/少称',
 status      TINYINT NOT NULL DEFAULT 1 COMMENT '1待退 2已退',
 created_at  DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
 KEY idx_order (order_id)
);

行级退款同步冲减对应佣金,两本账的联动要在同一个事务里完成。

生鲜的称重差异也要单独处理。团购按份卖,但水果蔬菜按斤进货,每份实际重量有出入。做法是下单时按份计价,到货后允许团长登记"少称"记录,平台按规则补差或者下次发货加量,小额差异免报处理。把"每单必须分毫不差"的执念放下,换成小额差异的批量化处理,履约成本和客诉都会下降。

团长提现和风控别做成事后补丁。佣金入账有 T+N 的确认期(覆盖售后窗口),提现走小程序内转账,单日限额和异常提现(新团长大额提现、多账号同设备)要有拦截。团购平台的资金安全事件,几乎都出在"佣金规则改了但历史订单没锁定"和"提现无风控"这两件事上,前面讲的"佣金下单时锁定"就是为这里埋的伏笔。

生鲜的称重差异也要单独处理。团购按份卖,但水果蔬菜按斤进货,每份实际重量有出入。做法是下单时按份计价,到货后允许团长登记"少称"记录,平台按规则补差或者下次发货加量,小额差异免报处理。把"每单必须分毫不差"的执念放下,换成小额差异的批量化处理,履约成本和客诉都会下降。

团长提现和风控别做成事后补丁。佣金入账有 T+N 的确认期(覆盖售后窗口),提现走小程序内转账,单日限额和异常提现(新团长大额提现、多账号同设备)要有拦截。团购平台的资金安全事件,几乎都出在"佣金规则改了但历史订单没锁定"和"提现无风控"这两件事上,前面讲的"佣金下单时锁定"就是为这里埋的伏笔。

五、团长体系:技术之外,数据要给团长看得懂

团长的留存决定平台生死,而团长最关心的是"我这个月挣了多少、哪个品好卖"。给团长的小程序端要有:佣金明细(逐单可查、提现记录)、本团销量排行、好货推荐(平台按区域动销数据推送)。技术实现不难,一个聚合查询加图表,但它让团长从"帮平台转发链接的人"变成"经营自己社群的老板",这个心态差别就是流失率差别。

六、小结

社区团购的工程主线:团次是一等公民、截团单据转换是骨架(采购单 + 分拣单 + 售后快照)、佣金下单锁定且跟履约入账、缺货走行级退款、团长端数据透明。青海青帝信息科技有限公司在本地团购类项目里,会先做"截团到分拣"这条链路的全流程演练再上线——这条链路断一环,到货那天几十个自提点同时乱掉,补不回来。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

目录
  • 一、核心对象:团次是一等公民
  • 二、订单与佣金:两层账要分开
  • 三、截团后的单据转换:这是团购系统真正的骨架
  • 四、到货与自提:状态推进靠扫描而不是手点
  • 五、团长体系:技术之外,数据要给团长看得懂
  • 六、小结
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档