企业官网建设流程全解析

做商品管理系统的这些年，我见过太多因为单位设置混乱导致的奇葩问题：仓库说按件入库，财务说按箱对账，门店要按包卖，月底一盘库存总是差那么几十、上百，查到最后全是单位换算的锅。今天就把“商品单位功能”这件事从头到尾拆开聊，它不是建个单位字典那么简单，牵扯到采购、销售、库存、价格、条码、报表整个链条。搞清楚它会让你少踩很多不该踩的坑。

这个功能的本质是：同一个商品，在不同业务环节里用不同计量单位，系统需要有一套机制来维护单位之间的换算关系，并且确保所有单据、库存、成本都按统一口径正确流转。做B2C商城、进销存、ERP、WMS系统的产品和研发，以及天天跟商品数据打交道的运营，都应该把这套逻辑吃透。

1. 商品单位功能到底是什么：一个商品的三套单位逻辑

1.1 从一包方便面说起：为什么不能只用一个单位

你去批发市场进货，方便面是整箱整箱搬的，一箱24包；到了配送中心，仓管员上架、拣货，更习惯说“这件、那件”，一件也是一箱；可收银台面对消费者的价格牌，写的是“2.5元/包”。同一个SKU，采购单上写“箱”，销售单上写“包”，如果系统只允许填一个单位，要么采购员每次心里折算，要么收银价格混乱，库存更是一笔糊涂账。

这就是商品单位功能存在的意义。它不是单纯把“箱”“包”“瓶”“公斤”做成一个下拉列表，而是要明确：同一商品在不同角色眼里的“计量粒度”不一样。采购关心的是整箱整件的搬运成本，门店关心的是消费者单次购买的最小包装，仓库和财务关心的是最终盘点、核算时能不能对得上。

我见过不少团队图省事，把商品主数据里只放一个“单位”字段，结果到订单层面只能靠运营在备注里写“100箱=2400包”。这种方案一开始能跑，商品一多就崩，而且历史数据全部无法追溯。所以单位功能必须是一个独立设计，而不是一个字段。

1.2 单位的两个基本要素：计量口径和换算关系

任何单位设计都逃不开两件事：一个是单位本身叫什么，另一个是它和最小粒度单位之间换算成几倍。最小粒度单位，我通常叫它“基础单位”或者“库存单位”，它是账实相符的锚点。为什么一定要锚定一个基础单位？因为只有把所有数量都折算到同一个粒度，采购入库、销售出库、库存盘点、成本核算才能用同一套数字去对账。

拿饮料举例，一瓶为“瓶”，一箱为“箱”，换算率是12，即1箱等于12瓶。这时候“瓶”就是基础单位，库存账上永远用“瓶”来记数。采购单上可以选“箱”，下单数量填100箱，系统入库时自动折算成1200瓶。销售单上可以选“瓶”，也可以选“箱”，出库扣库存时再统一折算回瓶。换算关系一旦确定，全链路都用它来计算，谁也不会再凭感觉说“大概二十几包吧”。

换算关系还有一个隐藏细节：它必须是单向清晰的，也就是“1个辅助单位等于多少个基础单位”，不要搞双向可逆还带浮动的逻辑。比如1公斤等于1000克，这是标准换算，没问题；但生鲜行业，一箱苹果可能重18公斤也可能19公斤，这就属于浮动换算率，是进阶玩法，基础设计阶段先别碰。

1.3 库存单位、采购单位、销售单位如何分工

一套完整的商品单位功能，至少要支撑“库存基准单位”“默认采购单位”“默认销售单位”三种角色。库存基准单位是内部记账用的，一般等于最小销售包装，也可能是最小可识别颗粒，比如“瓶”“个”“只”。默认采购单位是采购员下单时的首选单位，比如“箱”“托盘”，目的是减少采购沟通成本。默认销售单位是商品在前台销售时的默认展示单位，比如“瓶”“包”。

它们为什么不能随便混用？因为每个角色的业务目标和操作习惯完全不同。仓管员不可能在收货时把每箱拆开数出2400包来验收，他只需要按“箱”点数；门店收银员也不可能问顾客“你要24包还是1包”，顾客只会说“来一瓶”。系统要做的就是让不同角色面对各自熟悉的单位，同时在后端自动折算到同一个基准。

我建议在商品基础资料里把这三个字段单独列出来：库存基准单位、默认采购单位、默认销售单位。每个字段都关联到同一个计量单位字典，并额外存一个“相对基准单位的换算倍率”。有些系统还会加“采购单位默认价”“销售单位默认价”，这也没问题，但要把单位配置和价格配置明确拆开，否则后面调价时会拖泥带水。

2. 商品单位功能的系统设计与数据建模

2.1 数据建模：商品、单位、换算关系三张表怎么设计

既然商品单位不是单一字段，数据库建模就不能只给商品表加一个unit_id。至少要有三张表参与：商品表、计量单位表、商品单位关系表。计量单位表是最基础的字典表，维护“瓶”“箱”“包”“公斤”“米”这些单位名称，有些系统还会加英文缩写、符号，比如pcs、set、kg，方便对接第三方平台或打印标签。

商品单位关系表是整个设计的关键。它不能只存“商品ID+单位ID+换算率”，还要把每个单位在采购、销售、库存里的默认标记和价格语义存清楚。我自己常用的设计是：goods_unit_rel表，字段包括goods_id、unit_id、conversion_rate、is_base_unit、is_default_purchase、is_default_sales、purchase_price、sales_price、barcode。这里建议把价格放商品单位关系表，而不是单独放商品价格表，因为同一个商品在不同单位上的价格天然就是不同的。

下面是核心建表参考，字段精简过，实际项目可以按需扩展：

CREATE TABLE product_unit ( tenant_id BIGINT, product_id BIGINT NOT NULL, unit_id BIGINT NOT NULL, unit_name VARCHAR(50) NOT NULL, conversion_rate DECIMAL(18,4) NOT NULL DEFAULT 1, is_base_unit TINYINT NOT NULL DEFAULT 0, is_default_purchase_unit TINYINT NOT NULL DEFAULT 0, is_default_sales_unit TINYINT NOT NULL DEFAULT 0, purchase_price DECIMAL(18,4), sales_price DECIMAL(18,4), barcode VARCHAR(64), PRIMARY KEY (product_id, unit_id) );

conversion_rate字段的约定是：当前单位换算为基础单位的倍率，基础单位自身的rate固定为1。为什么要加tenant_id，因为SaaS系统多租户下，不同企业的“箱”可能装12瓶也可能装24瓶，这必须按租户和商品维度隔离，不能全局硬编码。还有很多系统会把换算率放到单独一张换算表，但商品维度优先，不建议在unit字典表里写死。

2.2 单据行里的单位字段为什么必须冗余

业务单据里一旦出现单位，字段设计就一定要冗余。什么意思？比如销售单明细行，除了记录商品ID、数量，还要把“当时选择的单位ID”“当时的换算率”“当时的单价”都冗余存储，而不是只靠关联商品主数据去推。

有人会觉得奇怪，商品资料里不是已经有换算率了吗，为什么还要在单据里再存一遍？因为换算率会变。今天供应商说一箱24瓶，明天可能换成20瓶包装，商品主数据里的换算率一改，历史单据如果只存数量不存当时的单位快照，金额、库存全部乱套。单据是业务事实，必须保留业务发生那一瞬间的上下文，不能受主数据变更影响。

我见过一个真实事故：改动了一个商品的换算率，结果三个月前的采购单全部按新换算率重新计算应付账款，财务对账死活平不了。所以只要涉及单位换算的单据，行表里至少要有unit_id、conversion_rate、quantity_in_base_unit、unit_price四个字段。quantity_in_base_unit是冗余的折算后基准数量，报表、库存、流水全部优先用它，不要每次都重新计算，既避免性能问题也减少精度偏差。

2.3 价格放在哪个单位上：单位价格体系设计

价格与单位的绑定关系，是商品单位功能最容易做歪的地方。很多系统只维护一个“销售价”，然后靠“销售价乘换算率”得到整箱价，这是完全错误的。整箱销售时给优惠价几乎是零售行业的默认玩法，你按单瓶价乘12再打个折，系统里就是说不清到底是打折还是调价。

正确做法是：每个单位可以有自己的价格字段，基础单位价格用于散卖场景，包装单位价格用于整件销售场景，两者分别录入。比如饮料单瓶3元，整箱售价30元，比单瓶价乘12便宜6元，这个价格就明确记录在“箱”这个单位的销售价里。采购侧同理，供应商给的价格是按箱报价还是按瓶报价，也应分单位存档。

还有一种常见模式是“一个商品的多个单位共用一套价格，但折扣单位不同”，例如12瓶装整箱参与满减。这种情况建议在商品单位关系表增加price_ratio字段，表示“这个单位的价格相对基础单位价格的倍率”，默认等于换算率，但可以单独覆盖。简单说，换算率管数量，价格倍率管计价，两者最好不要混在一个字段里。

3. 实操：商品单位功能从配置到全链路的落地步骤

3.1 上线前先回答六个问题

如果你正在给自己的系统加商品单位功能，别急着写代码，先拉着采购、仓库、销售、财务四个角色的代表开一次短会，把下面六个问题聊清楚。第一，你们说的“最小单位”是什么？第二，采购平时下单最常用哪个单位？第三，仓库收货、盘点最希望按哪个单位点数？第四，线上商城顾客买到的最小包装是什么？第五，财务对账、成本核算希望以什么单位出报表？第六，有没有不同供应商装货数量不一样的情况？

回答完这六个问题，基础单位、默认采购单位、默认销售单位基本就定了。以我经验，基础单位通常是“最小可销售单元”，因为销售决定了商品的最小颗粒需求；财务核算也喜欢最小单位，这样可以避免小数点后四位甚至更多的糊涂账。如果业务以整箱批发为主，基础单位也可以是“箱”，散卖场景再走拆零包装。

确定完后，要在系统里配置每一对单位关系。比如商品“苏打水500ml”，基础单位“瓶”，辅助单位“箱”，换算率24；默认采购单位“箱”，默认销售单位“瓶”；采购价30元/箱，销售价2元/瓶，同时箱销售价45元。这些数据录入商品单位关系表后，采购、销售、仓库各自看到的默认单位就都不一样，但后台库存数量始终按瓶在走。

3.2 一个12瓶装饮料的完整配置与流程演示

为了让你更有画面感，我用一个12瓶装饮料来演示完整链路。商品名叫“0糖柠檬饮料”，规格500ml。当前业务要求：采购按箱下单，每箱12瓶；门店按瓶销售，顾客也可以整箱购买，整箱价30元，单瓶价3元。

操作步骤按顺序是这样的。

步骤一，在计量单位字典录入“瓶”和“箱”，箱的换算率设置为基础单位的12倍。

步骤二，在商品资料里设置基础单位为“瓶”，默认采购单位为“箱”，默认销售单位为“瓶”。

步骤三，维护单位价格：瓶销售价3元，箱销售价30元；采购价假设18元/箱，不用再录瓶采购价，因为采购只会按箱。

步骤四，测试一笔采购单：开单时选择“箱”，数量填50箱，系统明细行自动显示折算后数量600瓶。审核过账时，库存表按600瓶增加，应付按50乘18等于900元。

步骤五，测试销售单：顾客买2瓶和1箱，销售单上可以一个明细分两行，一行单位“瓶”数量2，另一行单位“箱”数量1。过账时库存扣减方式为2瓶加12瓶，共14瓶，金额收2乘3加1乘30等于36元。

步骤六，盘点时看库存报表，显示的是“瓶”数和折算后的“箱”数并列，比如当前总库存“602瓶/50.17箱”。之所以会出现小数箱，就是因为仍有2瓶被拆散，这在拆零销售场景里非常正常，不要在报表里把“箱”数量取整，否则会对不上账。

3.3 不同业务场景的单位切换逻辑：拆零、整箱、混合结算

上面演示的是最标准的情况，现实中还会遇到“拆零销售”和“整箱拣货”同时存在。拆零销售意味着，整箱库存可以被拆开卖，系统必须支持一点：当销售单上选“瓶”时，库存是否允许从某个整箱里拆出来扣减。

我的建议是，库存账统一按基础单位记录，无论下单选箱还是瓶，最终扣减的都是基础单位数量；但仓库拣货环节需要一张“拆零汇总”提示。比如有10张订单一共要买36瓶，每箱12瓶，系统生成拣货单时可以直接提示“3箱整箱加0瓶”，然后拆箱3瓶给散单。这个逻辑的核心是：销售单位只是表达方式，库存扣减永远靠基础单位数量。

混合结算则是另一种场景，同一商品一行按箱、一行按瓶，在订单界面要能分别显示行小计，不要让“整箱价平均值”自动回填到散瓶价。不少人栽过这个坑：系统没有单独维护箱价，选择“箱”单位后，自动把单瓶价乘以12再打折9折，结果整箱价变成32.4元，和业务说的30元差出一截。所以单位价格卡片一定要先维护好，没有维护整箱价就不能允许选择箱单位开单，前端要给出提示。

4. 常见问题与排查技巧实录

4.1 库存对不上？先从单位换算精度找线索

最典型的库存异常是：库存数量出现小数，或者期末盘点后怎么都差了零点几。问题十有八九出在换算率的数据类型上。很多开发用整型存换算率，比如1箱=20瓶没问题，可一旦遇到1箱=12.375公斤，整型直接炸裂。即使存了小数，如果用Float字段做乘除，误差还会累积，1000行明细算下来能差出0.002，这在财务账上是不能接受的。

解决方案分三层。第一，数据库字段统一用decimal类型，比如decimal(18,4)，Java侧用BigDecimal，JavaScript项目也要用类似decimal.js的库，绝不用number直接做乘除。第二，所有库存流水表冗余一个quantity_in_base_unit字段，任何单位折算都只做一次乘法，结果写入这个字段，后续查询和汇总直接使用，不反复乘除。第三，在系统设置里明确“如果辅助单位数量除不尽，余数全部记入基础单位”，例如销售单上一行“箱”的数量为1，折算成24瓶，如果因为拆零导致剩余0.5瓶，那就真实记录0.5瓶，不要四舍五入。

4.2 价格混乱？多半是价格和单位没有绑定关系

单位功能另一个重灾区是价格。表现是：商品明明在商城显示“3元/瓶”，订单里却跑出来一个“0.25元/瓶”的单价，点进去一看，系统拿“箱价30元”除以“换算率120”了。听到这我相信你也明白了，价格混乱的根源就是没有把价格和单位绑定，而是在后端做了除法自动换算。

我的经验是，单位价格必须在商品单位关系表里独立维护，不要靠换算率推导。采购价、销售价、成本价每个单位各算各的，即使业务上允许“散买6瓶的价钱等于1箱”，也要在后台显示“箱价36元”，并由人工确认这是否就是整箱售价。如果确实希望自动带出，也要写明白是“等于基础单位价乘以换算率”，并且标明这是系统计算值，不是独立维护值，方便后续排查。

4.3 一张常见问题速查表

做了不少项目后，我把单位功能的高频问题整理成一张速查表，你可以直接当排查参考。

排查时我一般先看单据行里存的单位快照对不对，再看商品单位关系表里的换算率有没有被改动过，最后看价格来源。按这个顺序基本能定位80%的问题。

5. 进阶技巧：让单位功能真正好用起来

5.1 条码与单位绑定：扫码直接带出单位

现在电商后台和进销存都离不开扫码。条码如果只绑到商品，不绑到单位，就会出现一个很尴尬的场面：仓库扫了整箱的码，系统默认带出“瓶”单位，数量还得手工改。所以做完基础单位功能后，一定要考虑“一商品多单位，一单位一条码”的设计。

具体做法是商品单位关系表里增加barcode字段。散瓶的条码和整箱的条码各存一个，扫描枪扫到哪个条码，系统就自动识别出对应的商品ID和单位。特别是一些进口商品，外箱条码与内瓶条码完全不同，这个能力直接决定了仓库录入效率。

打印标签时也要带上单位信息，比如“1箱=24瓶”直接印在外箱标签上。很多WMS系统的打印模板不支持单位关系变量，我建议至少要用动态文本把当前单位名称和基础数量拼出来，否则仓管员每天靠脑子记箱规，迟早要出错。

5.2 浮动换算率：称重/计长商品的单位柔性

前文我提到浮动换算率，这里展开讲。生鲜、冻品、布料、电缆这类商品，理论上可以有一个标准换算率，比如“1盒=10卷”，但实际每盒重量可能不同。如果你死守着固定换算率，库存重量永远和实际称重对不上。

工业品和电商标品用固定换算率就够，场景复杂了对齐很痛苦。浮动换算率的设计思路是：基础单位仍然选一个固定颗粒，比如“卷”或“个”，称重结果作为辅助信息记录，而不是反过来用“公斤”做基础单位。例如布料按米销售，基础单位是“米”，入库单上可以记录“本次入库120米，实测重量36公斤”，这个重量只是批次属性字段，不参与数量折算，报表单独展示“每米克重”。这样既不影响库存数量，又能满足按订单重量发货时的统计需求。

如果业务真的必须以“公斤”为库存基准，比如大宗原料采购，那就把基础单位定为“公斤”，换算率对每个批次单独指定。这种情况下，商品单位关系表只能保存“默认换算率”，单据上还要增加字段让操作员录入“本批次实际换算率”。凡是涉及这种业务，我都建议在测试环境先用真数据跑两周，观察重量差异是否在可控范围。

5.3 报表与成本核算：用基准单位统一口径

单位功能做得好不好，最终要看报表。很多老板打开库存报表，看到“数量：12.5箱，均价：12元”就蒙了，这12元是箱价还是瓶价？所以报表一定要设计成“基准单位为主，辅助单位参考”的双列展示。

我举一个成品方案。库存余额报表：

这里的单位成本是基础单位的成本，不是箱成本。折算箱数只是给业务看的参考列，所有合计、对账都以第一列和最后一列为准。这样既照顾了仓库看箱的习惯，又保证了财务数字的严谨性。

成本核算同样建议只走基础单位。无论采购单以什么单位开，入库成本最终折算到基础单位。销售毛利也按基础单位成本算，然后再换算成销售单位的价格进行毛利分析。单位功能本质上就是把业务语言翻译成财务语言，中间不要有口误。

最后再分享一个小技巧

我在实际配置商品单位时，永远会在界面放一个“换算提示”：当用户选择“箱”时，旁边实时显示“1箱=12瓶，箱价30元，折合瓶价2.5元”。这个提示看起来不起眼，却能减少很多人工口算错误。商品单位功能看着简单，真正做闭环涉及采购、销售、盘点、价格、条码、报表六个环节，只要在一个环节偷懒，后面就是无穷无尽的对账。希望这篇经验能帮你少踩几个坑，如果你也在做类似模块，欢迎按这套思路去核对自己的数据模型，找出隐患再动手优化。