家禽商城销售系统设计：非标品、称重补差与批次追溯实战

“帮我搭个家禽商城销售系统，跟淘宝店差不多就行。”这句话是我一个做家禽养殖的朋友在电话里说出来的。他当时冷库里积了一批白条鸡鸭，想靠线上打开渠道，觉得找一套商城源码套件改一改就能上线。等我真坐到养殖场办公室，看完他们收禽、过秤、装笼、开证明、约货车的整套流程之后，才意识到这事跟“套个模板”差了十万八千里。

家禽产品有个特点：它不是标品。活鸡论斤、白条论只，同一只活禽宰杀前和宰杀后的重量能差出一两成；一批鸡今天这个价，下周可能另一个价；发货还要看是发活体还是发冷鲜，物流完全不是一个体系。把这些塞进普通电商系统的商品表、订单表、库存表里，不拆开重新设计，早晚会在某个环节爆掉。

那段时间我一边做需求一边跑市场，前后迭代了大半年，把商品建模、称重补差、订单状态、批次追溯、售后判定这些细节逐个捋清楚，踩了不少坑。这篇文章就把我自己做这套“家禽商城销售系统”时的核心设计决策和复盘写出来，给正在做农业电商、养殖场直销或者其他非标生鲜品类的朋友一点参照。

1. 非标品交易的底层差异：家禽系统到底在解决什么问题

想搭系统，先别急着画页面。先想明白家禽交易跟普通电商交易差在哪，不然做出来的功能一大堆，真正能用的没几个。

1.1 活禽、冷鲜白条、冷冻分割是三种完全不同的交易逻辑

家禽并不是只在“活体”状态下卖。我朋友这边就同时卖活鸡、白条鸡、分割冷冻品。这三种形态摆在一个商城里，表面看都是商品，实际上交易逻辑差得很远。我把它们拉了一张对比表，聊需求的时候直接拿这张表给对方看：

如果只把“活禽”当成一个普通SKU，那系统至少要在支付后增加一次“称重结算”；如果是冷鲜白条，要精确到生产日期和保质期倒计时；冷冻分割品则可以相对靠向普通商城逻辑。

我第一次做原型时把三种形态混在同一套商品模型里，想着无非多几个字段，结果一走到履约环节就卡住了：活禽订单需要“预约宰杀”，白条订单需要“计算剩余可售天数”，冻品要对接快递面单。这些动作不在同一个流程里，硬塞只能让代码越来越别扭。后来才明白，分类的边界必须在建表之前就定义清楚。

1.2 同一批货的买家不同，交付方式也完全不同

家禽商城上的买家，并不是只有普通家庭用户。

有一个人买两三只鸡回家炖汤的C端用户，她们通常对重量不敏感，只想知道“一只鸡够不够一家三口吃”；有餐厅后厨采购，每天下单固定要净膛后的白条鸡，要求上午十一点前送到厨房，价格按斤走，行情变了就得跟着变；还有县城做二批的客户，一开口就是“你们还有多少只，我全包”，要的不是商品详情页，而是当日可用批量和报价单，最好还能帮忙安排车。

这个差异直接影响系统的角色设计。只做C端零售的活禽商城，和要支撑批发订单的活禽系统，是两个不同物种。

我当时做了一个比较重要的决定：系统里区分“自营小批量零售”和“大客户认养/批量采购”两种下单入口。零售入口走正常的在线支付、称重、补差、快递或同城配送；批量采购入口则预留“先询价后支付”的流程。因为真正的批发交易很少直接按页面标价付款，大多需要电话或者微信谈好价格、数量、交付时间，再回到系统里线下支付备案。如果强行把批发也塞进“购物车→立即购买”的标准化流程里，反而会流失客户。

1.3 先画系统边界，别让营销功能拖慢核心链路

跟朋友讨论完业务，我给他画了一个模块优先级清单，核心顺序是：

• 商品目录与批次管理
• 订单与称重补差
• 活禽宰杀预约履约调度
• 批次追溯与证照入库
• 售后登记与补发退款
• 结算对账
• 内容页面、优惠券、会员等营销功能放在最后

很多农业电商玩家一开始最想做的就是“搞个好看的商城、搞个大转盘、搞个直播带货”，但家禽是低毛利、高复购的品类，它的客户来源大多是熟人介绍、社群复购、餐饮固定采购。靠一次大促冲进来的陌生人，如果服务体验没跟上，反而会带来一大堆售后。把基础的“今天下单、明天杀好、按时送到、重量不出大偏差”这四件事跑顺，比任何营销功能都重要。

想清楚边界之后，我才进入SKU设计。

2. 商品与库存的建模方式：SKU、称重补差和批次扣减

这一章是整个系统最容易翻车的地方。普通商城商品的建模套路是“品牌+类目+规格参数”，但家禽完全不是这么回事。

2.1 按“品种+形态+规格”去拆SKU

同一个“青脚麻鸡”，可以分成活禽、白条、分割鸡胸肉来卖。它们的库存、计价、物流、售后都不一样，必须拆成独立SKU，不能靠商品详情页里去描述。

我自己建SKU时用了“品种+形态+规格”的三段式逻辑：

这里有个特别容易踩的坑：光有“青脚麻鸡活禽”这个SKU还不够，同一个品种还得分公母、分重量区间。因为系统必须给用户一个重量预期，不能只写“一只”，否则用户以为买到了五斤大公鸡，结果发来一只三斤的，售后直接爆炸。把规格拆成“毛重2.5~3.2斤”和“毛重3.5~4.5斤”，每一档单独编码，前端展示和后端拣货都能对得上。

2.2 售价分两种情况：一口价和“先预估、后按称重结算”

家禽按斤称重是行业习惯，但让C端买家直接接受“每斤38元”有点费力，因为她们不知道一只鸡到底有几斤。很多商城会做“预估总价”，比如毛重3斤，预估114元，用户先支付114元，发货前实际称重后多退少补。

这个逻辑听起来简单，真正落地时有很多细节。假设用户预付的是毛重2.8斤、单价35元/斤，预估金额98元。第二天发货员实际称重3.1斤，实际金额就是108.5元。系统不能直接静默扣用户10.5元，得生成一笔“补差订单”，通知用户“你的鸡实际重量超出预估，需补差价10.5元”，等用户确认支付后，仓库才能打单出库。反过来也一样，实称只有2.6斤，系统要自动发起部分退款7元。

有朋友可能会问：直接统一按“只”卖一口价不行吗？比如标价128元一只，不称重了，省掉补差流程行不行？行，但前提是商家能把重量误差控制在合理范围内，并对用户预期做分级。比如把商品分成“3~3.5斤普通装”和“3.5~4.2斤大规格”，用户买哪一种，实际发货就在区间内浮动，价格已经预埋了平均重量和损耗。这种模式适合白条鸡或标准化程度较高的产品，不适合活禽现场交易。我做系统时两种都支持，区分方式是SKU上标记“计价模式”：fixed_price或weighed_settle。这个字段会决定后续订单流程走不走称重补差环节。

2.3 库存别挂在SKU上，要挂在“出栏批次”上

普通商城库存管理通常是“SKU库存数量=可用数量”，有人付款就减一。放在家禽场景里根本不够用。同样是青脚麻鸡活禽，5月1日进场和6月10日进场的那批，重量、检疫状态、能发货的时间都不一样；而且用户买活禽会指定“5月28号以后发货”，因为它需要长到对应重量。如果只维护SKU总库存，发货员根本不知道去哪个栏里抓鸡。

我的做法是引入批次库存表。一个批次包含这些属性：品种、栏舍号、进场日期、预计出栏日期、总数量、已锁定量、剩余可售量、平均重量区间、检疫证号、状态。用户下单时，如果这个批次还没到出栏日，可以上架预售，但要设置“预计发货日”，锁定该批次的库存。

批次库存的锁定量不是一次性扣减到零。用户付款后，锁定量增加；等到出库真正装车、人手点完数量之后，才把锁定量转成实际出库量。用两个字概括就是“预占”，这样才不会发生同一批鸡被两个渠道同时卖掉的情况。农产品库存很容易出现“道理我都懂，但账上跟栏里对不上”的局面，批次预占是必须做的基础功。

3. 订单状态机和履约操作：宰杀时间要成为一等公民

模型建好之后，接下来是订单流程。订单流程里的猫腻比商品建模还多。

3.1 “待发货”状态在家禽场景里根本不够用

普通电商订单状态就是“待付款→待发货→待收货→已完成”，偶尔加个售后状态。家禽系统如果照搬，仓库一定会被逼疯。

一个活禽订单从产生到完成，至少要经过这些动作：用户下单、预约宰杀日期、商家确认批次、安排宰杀、宰杀后称重、生成补差单、包装贴标、装车出库、物流揽收、用户签收。我觉得完整的订单状态应该设计成这样：

• 待付款
• 已付款/待预约
• 已预约/待商家确认
• 待宰杀
• 已宰杀/待称重
• 称重完成/待补差
• 补差完成/待发货
• 已出库/配送中
• 已签收
• 已完成

别嫌状态多，每一个状态背后都对应一个真实操作人。拿“待宰杀”来说，用户下单时通常会选“5月30日下午杀好，当天同城送”，那么屠宰员在5月30日上午打开工作台，应该看到一张“今天要杀哪些鸡”的列表；如果某些用户没有预约，订单就只能停在那里，绝不能默认排入当天宰杀队列。把宰杀节点显式地放进订单状态机后，仓库的排产逻辑才清晰。

3.2 同一个订单要拆成多个“履约单”，因为物流不能混送

一个用户可能在同一个订单里买了活鸡和冷冻鸭掌。活鸡要走同城活体配送，鸭掌可以走冷冻快递，两种物流不能放在同一个包裹里。订单拆分的常见做法是引入“履约单”：一个父订单对应多个发货单，每个发货单有独立的物流公司、运单号和状态。

再往细里说，连自己的出库单也最好独立建模。比如同一个订单里两只活禽，一只上午预约宰杀，一只因为规格缺货要等到下午，那系统就应该把它们拆成两个子订单，而不是等全都备齐再整单发出。用户看到的部分是“订单部分发货、部分发货”，商家和仓管各干各的活，互不干扰。我刚开始没做拆单设计，遇到一次用户买活鹅又买冻鸭的订单，整个流程卡在活鹅要单独等车，冻鸭已经在冷库化冻了，吃了个大教训。

3.3 称重补差和售后退款必须跟订单明细挂钩

如果没有称重补差，订单金额在付款那一刻就固定了，后面所有操作都简单。可一旦引入补差，钱就变成了动态的：用户多付或少付，钱从哪里来、到哪里去，都要能查到原因。

我落地时做了一张“结算调整单”，不管是补差、折扣、重量差额退款还是部分商品退货，都不会直接改原订单金额，而是生成一笔调整记录，关联到具体订单明细。比如用户买了两只白条鸭和一只活鸡，活鸡实际重量少了，要退7块钱，那这7块钱必须落在“这只活鸡对应的订单明细行”上，而不是粗暴地对整个订单执行退款，否则后台对账的时候就会糊成一片。

在数据库设计上，订单明细表order_item至少要预留actual_weight、listed_price、estimated_amount、final_amount这几个字段，并给一个金额状态，标记这笔明细是“待称重”“预估待结算”还是“已结算”。不然财务月末一拉账，全是漏算。

4. 追溯与食安信息设计：批次、证照和出库标签怎么关联

家禽属于入口食品，活禽还要涉及防疫检疫，追溯不是可有可无的锦上添花，而是每一个发货批次都要有的基础信息。系统能不能稳定发货，很大程度上取决于这一块做得好不好。

4.1 把证照文件当成“商品发布的前置条件”

很多农产品电商平台会把资质审核做成入驻时的一次性动作，提交完营业执照后就不管了。但家禽不一样，证照是有时效的，而且发货时，部分地区要求证明随货，不能只停留在线上备案。我在系统里设计了一个证照管理模块，商家可以上传产地检疫合格证明等文件，并设置有效期。

关键点是，这个证照文件不能“挂在店铺页面上好看”，它应该跟具体的商品批次关联。某个批次入库时，系统要求填写检疫证编号，并上传对应照片。等到该批次库存变为0，证明文件也归档留底。这样一旦有客户或者市场需要查，后台可以按批次一键调出所有资料。

4.2 批次追溯要能落到出库单上

做追溯时最容易犯的错是把追溯做成“事后查询”。正常查询是在出库环节就要体现出来：打印发货面单的同时，把这张单对应的批次信息和证照信息一起打出来，或者至少生成一个二维码，印在包装标签上。

顾客扫码如果能看到产地信息、出栏日期、入场日期、屠宰日期、检疫证照片，那种“知根知底”的信任感是直发小作文替代不了的。很多消费者不是专业人士，他们看到标签上有个可扫的码，会觉得系统正规、商家靠谱。

实现上，出库流程是：发货员扫码或输入订单号 → 系统展示待出库明细 → 发货员确认批次 → 打印标签。如果某个批次没有上传证照，这一步直接弹窗拦截，不允许出库。这种“硬拦截”比事后人工检查可靠得多。有一个批次的鸡因为临时补货，商家想跳过证明先发出，被系统拦住，虽然当时对方觉得麻烦，但后来某次抽查遇上检查，才发现这步没白做。

4.3 标签打印要配合真实仓库场景来设计

追溯标签最好跟称重环节绑定。称重终端显示订单信息，录入实称重量后自动打印，标签内容包括：商品名、批次号、净重量、发货日期、出库单号，以及一个追溯二维码。

现实里家禽仓库环境并不友好：冷库温度低、档口潮湿、操作员可能戴着手套，手里的扫码枪和打印机经常连不上网。因此，系统要支持离线称重