去年，我们团队接手了一家年营收8亿的中型快消品公司的ERP二次开发项目。上线后第三天，财务总监打电话过来，语气平静得可怕：“系统里的库存金额和我们手工账差了47万，你们查一下。”排查了整整两天，问题锁定在一个绝大多数开发教程都草草带过的地方，多计量单位换算的配置策略出了问题：采购用“吨”入，仓库用“箱”存，生产用“公斤”领，销售用“瓶”出，四个单位之间的换算关系在第一次配置时做错了两个优先级判断，整个成本核算链条从源头就歪了。这篇文章不是“多计量单位功能的使用说明”，而是把这个模块真正做对、做稳、做成一笔不会反噬的账的系统性拆解，我会把踩过的坑、验证过的配置原则、推荐的数据库设计策略，以及财务核算端的致命逻辑，一次讲清楚。
在进入详细拆解之前，先把核心判断放在最前面。这些结论来自我过去七年参与过的11个ERP/WMS实施项目，其中4个出现了与多计量单位直接相关的重大数据事故。
第一，多计量单位换算的本质不是“数值映射”，而是“业务语义映射”。当你把1箱设为等于12瓶，你在做的不只是定义一个除法关系，你是在向系统声明：采购的“箱”、仓库的“箱”、销售的“箱”到底是不是同一个东西。大多数配置错误都源于没有区分这三种语义。
第二，固定换算和浮动换算是两套完全不同的系统架构，不能共享同一套配置逻辑。固定换算可以用静态换算率表解决，浮动换算（按实际称重、按实时测量）必须考虑时序性、凭证锁定和差异容忍度。强行用固定换算的思维去配置浮动业务，得到的一定是月末无法对账的烂摊子。
第三，主单位的确定规则决定了整个库存账的稳定性。一个系统中，必须存在一个且唯一一个“库存基准单位”，所有业务单据上的任何单位最终都必须可追溯到这个基准单位。这个原则一旦在配置阶段妥协，后续的成本核算、库存账龄分析、呆滞报表全部会出错。
第四，精度问题不是技术问题，是管理问题。系统无法替业务决定“几分钱差异是否可接受”，但它必须提供全局精度规则配置能力，并在报表层和应用层分别执行不同的小数位策略。这个设计决策必须在开发阶段完成，上线后改不动。
2019年在广州做的一个项目，客户是一家调味品企业，主打产品是蚝油。业务流转路径是：采购部门向供应商下单，以“吨”为单位签合同、结算；货物到达后，仓库按“箱”（12瓶/箱，每瓶500克）进行码盘和入库登记；生产部门领料时，系统要求以“公斤”为单位记录消耗量；而销售部门出库给商超渠道时，单据上写的是“瓶”。
四个单位，三种换算关系。但问题不在换算本身，小学四年级的数学就能完成12瓶×500克=6公斤，1吨=1000公斤≈166.67箱的计算。真正的问题在于，当初的调研阶段，项目组只确认了“系统支持多单位换算”这个功能点，没有进一步追问三个关键问题。
问题一：业务上是否存在“同一物料根据批次不同，换算率会改变”的情况？这个客户有一款促销装，旧版本是12瓶/箱，新版本因瓶子材质更换，改成了10瓶/箱。SKU编码没有变（因为规格参数一致），但物理容积变了。如果系统只支持“一个SKU对应一个固定换算率”，这就直接进入了死胡同。
问题二：财务核算是按哪个单位作为成本计算基准？多数企业按最小库存单位计价，但也有例外，比如采购合同金额是以“吨”为单位的完整报价，财务希望入库单价保留“吨”口径，用于与供应商对账。这意味着系统必须在“吨”和“瓶”两个口径上同时维护成本记录，而不是简单的单位转换。
问题三：盘点、退货、损耗这些逆向业务流中，单位如何取数？退货时，商超退回的是3瓶，仓库要按箱归集，损耗登记按公斤记录，这条反向链路如果不提前设计，逆向单据一定会抛异常。
化学品、生鲜、金属材料、布料卷材这四个行业是多计量单位事故的高发区，因为它们大量使用浮动换算，即换算率不是固定值，而是每次交易时根据实际测量确定的。
2021年在南京一家化工企业，硫酸采购以“吨”过磅计价，入库后存储在罐体中，按“立方米”管理库存，生产领用时流量计以“公斤”为单位输出消耗量，而销售给下游的电镀厂时，合同单位又是“吨”。这条链路上，“吨⇄立方米”的换算依赖硫酸在当前温度下的密度值，夏季和冬季差异明显。系统如果只支持一个全局的硫酸密度换算系数，而不是按入库批次分别记录实际密度，库存账面上的“体积余额”和“质量余额”就会在季节转换时出现系统性偏差。
这类场景的开发和配置有一条铁律：浮动换算必须由前端业务单据（入库单、发货单）在操作时实时采集并锁定换算率，系统后端不做任何自动重算。一旦允许系统在对账时“帮你重算一遍”，你就在制造一场审计灾难。
很多开发团队上来就建一个产品主表，然后在主表里塞一个“换算率”字段了事。这是最常见的错误，也是后期改不动的根源。
正确的顺序是：先设计独立的单位字典表，再定义单位组，最后把单位组关联到物料。这个顺序不能颠倒。原因在于，同一家企业中，不同物料类别的单位体系可能完全不同。食品行业可能用到“箱、包、袋、瓶”，建材行业用到“吨、包、根、平方米”，如果按物料逐一配置换算关系，不但维护效率低，更重要的是换算出错概率会随着SKU数量线性上升。
我们团队目前遵循的数据库设计规范如下：
— 单位字典表（系统级）
CREATE TABLE unit_dict (
unit_id VARCHAR(10) PRIMARY KEY, — 如 'TON', 'KG', 'BOX', 'BTL'
unit_name VARCHAR(20) NOT NULL, — 吨、公斤、箱、瓶
unit_type VARCHAR(10) NOT NULL — 重量/体积/数量/长度
);
— 单位组表（物料类别级）
CREATE TABLE unit_group (
group_id INT PRIMARY KEY,
group_name VARCHAR(30) NOT NULL, — 如 '调味品标准单位组'
base_unit_id VARCHAR(10) NOT NULL — 组内基准单位，如 'KG'
);
— 单位组换算关系表
CREATE TABLE unit_conversion (
conversion_id INT PRIMARY KEY,
group_id INT NOT NULL,
from_unit_id VARCHAR(10) NOT NULL,
to_unit_id VARCHAR(10) NOT NULL,
conversion_type VARCHAR(1) NOT NULL, — 'F'固定 / 'V'浮动
rate DECIMAL(18,8) NULL — 固定换算率值（浮动时为NULL）
);
关键设计决策：基准单位必须在单位组级别定义，不能下放到物料。这是从那个47万差异事故中学到的教训，如果基准单位允许每个物料自行定义，当采购、仓库、生产三个部门各自维护同一物料的主数据时，一定会出现基准单位不一致的情况，而系统在这个层面没有任何校验能力。
库存系统的单据行表（采购入库行、销售出库行、生产领料行等）在设计时，有一个容易被忽略但极其重要的原则：禁止在需要查询时通过单位换算表实时计算当前单据行的数量。每一次业务发生时的换算关系，必须在单据行上冗余存储。这是保护历史数据一致性的根本手段。
每张单据的明细行，至少需要冗余以下四个字段：
| 字段名 | 含义 | 必要性说明 |
|---|---|---|
| business_unit | 业务发生单位（录入单位） | 用于单据展示和业务员核验，保留操作痕迹 |
| business_qty | 业务单位数量 | 录入的原始数值，不可篡改 |
| base_unit | 对应的基准单位 | 该物料在单位组中的基准单位，用于库存账更新 |
| base_qty | 基准单位数量 | 按换算率转换后写入，是库存余额变迁的唯一依据 |
这四个字段中，base_qty的写入时间点必须严格控制在“单据提交时”，而非“单据审核时”或“报表查询时”。原因是，单据审核可能发生在提交之后数小时甚至数天，如果期间有人在主数据中修改了换算率，审核时基于新换算率自动重算base_qty，将导致库存账在不知情的情况下被改写。
当业务要求同一SKU不同批次允许不同换算率时，换算率不再属于物料主数据，而必须上升到“物料+批次”维度。设计上强烈建议：不在物料主表或批次表中直接存换算率，而是将每个批次的换算率独立存储为一张批-单位映射表。
CREATE TABLE batch_unit_mapping (
mapping_id INT PRIMARY KEY,
sku_id INT NOT NULL,
batch_no VARCHAR(30) NOT NULL,
from_unit_id VARCHAR(10) NOT NULL,
to_unit_id VARCHAR(10) NOT NULL,
rate DECIMAL(18,8) NOT NULL,
effective_from DATETIME NOT NULL,
effective_to DATETIME NULL
);
这种设计的额外好处是，它天然支持换算率的变更追溯。当财务质疑某笔出入库单的成本计算依据时，直接查这张映射表的生效时间窗口，就能做到审计级别的证据留存。
这是我见过的最严重的术语混淆问题，且大量国产ERP软件的配置界面本身就加剧了这种混淆。
基准单位是系统底层计算用的唯一单位，用来保证库存数量账簿的一致性。它是不可见的，业务人员不需要感知。主单位是展示给用户看的默认单位，可以在报表、单据界面根据用户偏好切换。
正确的配置原则是：基准单位确定后，任何一个物料在整个生命周期内不得变更；主单位则可以根据业务角色自由配置，且不必与基准单位一致。如果一个ERP系统不区分这两个概念，或者在配置界面把“主单位”直接等同于“基准单位”，这个系统的底层库存计算一定是不可靠的。
精确到小数点后2位还是后8位，不是单独某个单据的问题，而是系统级的配置决策。开发阶段必须提供一个全局精度配置入口，至少覆盖：
这四条路径必须做到“存储精度 ≥ 计算精度 > 展示精度”。如果你发现自己的系统里一条单据行上业务数量×单价不等于金额（差了0.01或0.02），问题就出在“计算时用了展示精度而不是存储精度”。修复这个问题的成本，在上线前只需要改一行配置；上线后，需要技术团队对全量历史数据进行重算并出差异调整单。
在一个单位组里定义了“吨→公斤”和“公斤→克”的换算，系统是否自动推导出“吨→克”的换算关系？很多系统为了灵活，默认开启了这个推导功能。
永远关闭自动推导。原因很简单：自动推导依赖链路上的每一步换算率都绝对精确，而实际上“吨→公斤”可能只是1:1000的近似表达，真实业务中存在0.1%-0.5%的允差。当多条换算链在系统后台自动交叉传播时，误差会以不可预测的方式放大。要求每一条跨级换算关系都必须显式定义，虽然增加了主数据维护的工作量，但堵住了最大的系统性误差来源。
这是快消品促销季的高发问题。年初定义“1箱=12瓶”，年中推出促销装“1箱=10瓶”，SKU编码未变。如果管理员直接在主数据界面把12改成10，系统内所有未关闭的采购订单、未出库的销售订单、正在流转的生产工单，它们的base_qty参照什么标准？
解决这个问题的唯一正确方式是“换算率版本化”，即每次修改换算率时，系统自动生成一个新的换算率版本号，已提交的历史单据绑定当时的版本号，新单据默认引用最新版本。这不是可选功能，是防止批量数据污染的基础设施。
正向流“吨→箱→公斤→瓶”设计得很漂亮，一到退货、损耗登记、质检降级这类逆向场景就开始报错了。原因是开发阶段只设计了一条单向映射路径，逆向时没有定义“当用户录入瓶数时，如何反算箱数”。
正确的做法是：对于单位组内的每一对单位（from_unit, to_unit），必须同时存在正向和反向两条换算关系记录。在一条退货单上，业务员录入的是“退货3瓶”，系统查找“瓶→箱”的换算记录（而非“箱→瓶”的取倒数），这样每一条映射都可以单独配置小数位含入规则，而不是依赖系统自动求倒数后产生的长尾小数。
集团型企业中，A工厂用“吨”管理原料，B工厂用“公斤”管理同一批原料。当A向B调拨100吨时，如果两个组织的主数据维护独立，B收到的是按实时过磅重量折算的公斤数，B的系统可能无法直接识别出这笔货对应A出库的哪条单据行。
解决方案是：集团级单位组必须作为各组织单位组的超集存在。组织可以有自己的本地化单位，但所有组织都必须能映射回集团基准单位。调拨单据上的数量以集团基准单位为准，同时冗余两个组织的本地单位数量，以保证各自的库存账能独立更新。
这是开发阶段第一优先级的功能。它不是一个复杂的模块，但几乎所有项目的早期版本都缺失了它。
校验引擎需要在每次单位组配置保存时自动执行以下检查：
这个引擎应该打包成一个独立的校验服务，在配置保存、批量导入、数据迁移三个节点都触发执行。上线前用一批故意构造的错误数据去跑这个引擎，确保它能捕获所有已知的异常模式。
当管理员申请修某一个物料的换算率时，在点击“确认”之前，系统应该自动呈现一份影响分析报告，列出：
这个功能的价值在于：它不是程序员要的，是财务经理要的。如果系统的配置变更没有这种预检机制，财务永远不会信任你的库存报表。
浮动换算场景中，过磅重量通过PDA实时回传系统。如果同一批物料在过磅的同时，仓库管理员在PC端操作了入库单的审核，这两个动作存在并发竞争。
开发上必须做到：当一张单据行上存在浮动换算字段且该字段处于“待采集”状态时，整条单据行加锁，禁止审核、禁止关联下游单据生成、禁止任何库存余额更新操作。锁释放的条件是：浮动换算的测量值写入完成，且经过预设的“合理值范围校验”（如重量不能为负数、密度不能超过物理可能区间）。
盘点时，仓管员用PDA扫描了某个批次的100箱，系统库存显示应该是102箱，差异2箱。问题在于，这2箱差异在追溯到上游时，是以什么单位呈现的？如果采购入库时用的是吨，生产成本核算用的是公斤，盘点差异最终需要分摊到每次入库的成本调整上，系统必须能自动完成这条追溯链：“差异2箱 → 差异12瓶 → 差异6公斤 → 差异0.006吨 → 对应采购单X的成本应调减XX元”。
这个功能不做，盘点的后续处理就只能靠人工线外计算。上线后数月内，盘点差异都会是财务和仓管的持续冲突点。
前面说过，基准单位一经设定不可变更。但如果业务真的发生了变化，比如此前维护错误，把“瓶”设成了基准单位，而现在发现基准单位应该是“毫升”，怎么办？
系统不应该留一个“超级管理员密码”来绕过这个禁锁，那会毁掉所有数据一致性约束。唯一正确的方式是提供一个“物料基准单位迁移流程”：旧物料冻结（禁止新的出入库），新建一个正确的物料编码，通过调拨单把旧物料的库存余额按实际换算率转移至新物料。这条调拨单本身就是审计证据。迁移完成后，旧物料标记为“已停用”，所有历史报表查询照常，新业务的单据全部引用新物料。
不要追求功能完整性。固定换算已经完全够用。关键是：强制所有物料统一使用一个基准单位体系（建议统一到最小销售单位），不要允许不同物料类别自行选择基准单位。统一带来的好处是，所有人员的操作习惯一致，培训成本极低。代价是某些物料（如大批量采购的原料）在单据上显示的数量数字很大，但这个缺点远小于单位混乱带来的风险。浮动换算如果确实需要（如生鲜按实际称重），只允许在采购入库这一个环节使用，入库后立即转为固定换算进入库存系统。
这是事故最高发的群体，因为业务复杂度已经超出了简单配置的承载上限，但IT预算和系统架构能力还没有跟上。
中企必须做的三件事：第一，实施单位组的概念，禁止单物料配置换算率。第二，引入批次级换算率，但限制浮动换算的使用范围（仅在采购、委外加工两个环节开放）。第三，部署换算率变更影响分析模块。这三项不做，三年内一定会出一次严重的库存数据事故。除此之外，中企的财务通常已经开始要求多维度成本核算，这意味着基准单位上的成本单价必须与业务单位上的销售单价形成可追溯的计算链路，单据行上的四个冗余字段不能省。
大型企业在多计量单位问题上，核心挑战不是“能不能支持”，而是“如何在既有异构系统中保持一致”。很多大型企业的IT系统是逐年叠加的：ERP是一个厂商，WMS是另一个，生产制造MES是第三个，每个系统都有自己的单位处理逻辑。
大企的刚性需求是：由集团统一发布基准单位标准，各子系统在内部可以保留各自的本地单位，但所有与集团级系统（如合并报表、集团ERP）的接口，必须只传输基准单位数量和版本化的换算率快照。同时，大企必须部署换算率的主数据管理平台（MDM），所有换算率的变更都走审批流，审批通过后由MDM向各子系统同步。任何子系统不得在本地自行修改与集团基准单位相关的换算关系。
特别提醒大型企业的技术团队：不要尝试做一个“万能换算引擎”来兼容所有历史系统的单位规则。这类引擎在纸面上可以描述得很完美，但在实际运行中，不同系统间的换算率版本不同步、时间戳不完全一致、小数位策略各异，会导致引擎本身成为最大的不确定因素。宁可用“脏但明确”的逐系统对接方案，也不要用“聪明但不可审计”的中心化转换引擎。
以下五个用例是我们在每个项目上线前强制执行的回归检查项。任何一个不通过，不允许切换生产环境。
创建一个采购订单（单位A）→ 生成入库单（自动换算为单位B）→ 库存余额更新（基准单位C）→ 生成销售出库单（单位D）→ 检查出库单上的数量、单价、金额是否与原始采购形成正确的追溯链。允许的差异：金额尾差不超过0.02元（因小数位含入）。
同时启动两个线程：线程一持续尝试审核一张等待过磅数据的入库单，线程二模拟PDA上传过磅重量。验证线程一在所有数据写入完成前始终返回“锁定状态”错误码，线程二写入成功后锁自动释放，线程一可以正常审核。
在系统中创建一张未审核的出库单，单据上商品的换算率为“1箱=12瓶”。然后管理员在主数据中将该商品的换算率改为“1箱=10瓶”。审核此前创建的那张出库单，检查base_qty是否仍然按照12瓶计算（历史版本），而新创建的另一张出库单是否按照10瓶计算（当前版本）。
模拟一条完整的退货链路：销售出库100瓶 → 客户退货23瓶 → 质检判定15瓶可二次销售、8瓶报废 → 15瓶返回仓库生成入库单，系统以“箱”为单位记录 → 8瓶报废以“公斤”为单位记录损耗。检查每一步的单位换算是否正确、损耗登记是否自动扣减了对应的库存余额、可二次销售的15瓶对应的成本和批次是否与原始出库关联。
构造一个包含500条换算率配置的Excel文件，其中故意混入3条异常数据：一条存在单位环路、一条重复定义了已有的单位对、一条浮动换算与固定换算冲突。执行批量导入，验证系统是否准确拦截了这3条异常记录并给出了清晰的错误提示，同时其余497条正常数据是否完整导入且关联关系正确。
这是财务端最核心的原则，但不少系统在实现上走了捷径。如果成本计算直接在业务发生单位上做加权平均，会导致同一物料在“吨”和“公斤”两个视图下出现完全不同的移动平均成本，因为不同批次的入库可能选择了不同的业务单位。
正确的实现方式是：所有入库单行上的金额首先折算为基准单位单价（金额 ÷ base_qty），所有成本计算（移动平均、先进先出、个别计价）均在基准单位维度展开，出库时再根据出库单行的业务单位反算出业务单位下的出库单价。
浮动换算带来的一个隐性财务问题是：同一SKU，不同批次因实际过磅重量不同导致实际入库单价不同。如果系统将它们合并到一个成本池中做加权平均，实际过磅较轻的批次会被较重批次“补贴”，导致毛利率分析失真。
处理原则是：浮动换算批次默认开启批次成本独立核算。财务可以事后决定是否将这些批次合并计算，但系统默认不合并。这个设计把决策权交给了财务部门，而不是让系统替他们做假设。
供应商用“吨”口径对账，仓库用“箱”口径盘库，财务用“元”口径结算。任何一张跨部门使用的对账报表，如果只展示单一单位数量，一定会导致至少一方质疑数据来源。
设计和财务部门达成一项约定：所有跨部门流转的库存相关报表，必须同时展示基准单位数量和业务发生单位的原始数量。这会给报表查询增加额外的SQL join，但换来的对账效率提升远超这一成本。
上线一年后，很多企业会出现一种常见的“权限失控”：为了响应业务部门的灵活性需求，IT部门逐步放开了部分物料主数据的维护权限给到业务主管，其中包括换算率的修改权限。这个决定通常是在一次紧急需求中被临时批准的，之后没有收回。
换算率的修改权限必须只属于主数据管理团队，不允许下放到业务部门。如果业务部门频繁提出换算率变更需求，说明不是权限问题，而是业务流程中存在需要解决的根源问题，比如促销包装的版本管理没有纳入产品生命周期管理流程。放权解决不了这个问题，只会把数据质量风险从IT部门转移到整个公司的库存账簿上。
当系统运行三到五年后，会出现数据归档需求。归档时很容易犯的错误是：只归档了单据行上的业务数量和基准单位数量，但没有归档当时的换算率快照。
一旦归档后主数据中的换算率发生了变更，再想把归档数据拉回来和当前数据进行同比分析时，就会出现单位口径不一致的问题。归档策略必须包含一张独立的“换算率历史快照表”，与归档单据绑定存储。
当企业上线新的业务线或收购新的子公司时，系统往往会新增物料编码和单位体系。这个阶段最大的风险是：新单位体系与老单位体系在字面上相同但语义不同。
比如老业务中“箱”=12瓶，新业务中“箱”=24瓶，但两家公司使用同一个单位字典表。如果直接复用，数据污染会在合并报表时集中爆发。建议在单位字典表中增加“单位所属业务域”的字段，并设置跨业务域引用时的强制校验规则。
多计量单位换算是个老话题，但在中国企业普遍从粗放经营转向精细化数据驱动的当下，它的重要性正在升级。过去，差几箱、差几十块钱，用Excel拉一下就能平账。现在，当一个企业的库存周转率每提升0.1次就能释放上百万现金流的时候，多单位换算已经不是功能支持问题，而是数据资产的治理起点。
如果你现在正在做系统选型或二次开发，把前面列出的五个上线校验用例拿给技术团队看，确认每一项都有对应的实现方案和测试计划。如果你已经上线、正在被历史数据差异困扰，先从“单据行是否冗余存储了基准单位数量”这个点查起，根据我的经验，超过一半的差异问题最终都定位在这个字段的缺失或写入时机错误上。做完这个检查，再对照第六节的配置陷阱逐项排查，你不需要重做整个系统，通常只需要修正两到三个关键的配置项和补齐缺失的冗余字段，差异就能被控制到审计可接受的范围内。
我公司做生鲜批发的，采购按斤入库，销售按盒出库。上了库存系统后发现成本总是对不上，系统说支持浮动换算，但月底盘亏一大堆。到底浮动换算的实时准确是怎么实现的？我该信吗？
浮动换算的难点在于实际业务中每次出库的换算率都可能不同，但很多系统为了简化，只在配置里写一个固定换算率，然后声称支持浮动。这不是浮动，这是诈欺。真正的浮动换算需要在每次出库/入库时记录实际重量/体积，比如采购20斤草莓，单价5元/斤，成本100元。
销售时顾客要3盒，每盒实际称重分别为0.18斤、0.22斤、0.2斤（总计0.6斤）。系统的正确做法是：出库3盒，每盒记录实际重量，库存减少0.6斤，成本按加权平均法分配（例如库存单价5元/斤，出库成本=0.6×5=3元）。
但很多系统只记盒数，然后按配置的固定0.2斤/盒扣减4盒*0.2=0.8斤，导致库存虚增、成本错乱。我们去年测试了7家主流SaaS库存系统，真正实现每次出入库都写入实际换算率的只有2家，其余都是存一个固定换算率字段。
验证方法很简单：用不同实际重量的盒陆续出库，看月底的库存数量与实地盘点是否一致，误差超过0.5%就说明是伪浮动。我建议选型时直接要求对方提供API文档，看每次出库接口是否能传入实际换算率参数，不能就pass。
我们产品包装规格变了，但之前有很多未完成的订单和库存。我改了系统里的换算率后，发现之前的老单据数量全部乱套，财务部抓狂。难道历史数据就只能废掉吗？有没有办法让换算率的变更不影响历史单据？
我踩过这个坑，代价是运维团队连续加班两周手动修正了3000多张单据。问题核心在于：换算率是配置在主数据上的“活值”，而历史单据上的换算率是被“冻住”的。常见错误方案：直接修改主数据的换算率，然后所有历史单据自动套用新率，导致库存数量、金额全部错乱。正确做法是引入“时间戳换算率”或“单据级换算率”。
两种策略对比：①时间戳换算率：在换算率表中增加“生效日期”，查询历史时根据单据日期取对应换算率。优点是完全不变历史，缺点是开发复杂、查询性能下降。②单据级换算率：在每张出入库单据上存储当时的换算率，新增换算率时系统自动给当前未关闭的单据锁定旧率。优点实现简单，缺点未关闭单据需标记。
我实战中推荐第二种，因为90%的场景只需锁定未结单据。具体操作：配置新换算率时，系统弹出对话框询问“是否强制应用到未结订单？”，选否则仅新单生效。别忘了还要同步更新成本计算表里的换算率字段。我们上线后专门写了一个SQL脚本定期检查换算率变更日志与成本表的差异，误差控制为零。
测试方法：变更后，导出变更前后各一张老单据的库存数量金额，人工验算是否一致。
我们采购用吨，库存管理用公斤，销售用袋（25kg/袋）。系统配置好后，发现销售出库时库存数量对不上，采购进来100吨，库存显示10万公斤，但袋数却是4000袋（按25kg算），但实际称重有浮动。到底应该以哪个单位为准？有没有统一的法则？
最大的错误：让各业务环节直接用自己的单位独立计算，没有统一的“原子单位”。我见过最混乱的设计，采购单存‘吨’，库存台账存‘公斤’，销售单存‘袋’，系统里三条线各自为政，对账全靠Excel。数据一致性必须靠一个原则实现：所有业务模块的数量最终都换算为同一个最小单位（推荐库存管理单位）存储和计算。
例如用公斤作为原子单位。采购单来了100吨，入库时必须转化为100,000公斤写入inventory表，同时记录原始单位“吨”作为显示辅助。
销售出库时，客户要10袋，但袋是可变单位，必须先确定这10袋的实际公斤数（比如通过PDA称重250kg），然后从库存扣减250公斤，同时在销售单行上记录“10袋/250kg”。这样库存表中的数量永远是公斤，加减无歧义。
我们曾帮一家食品企业整改，原来采购、库存、销售分别用箱、个、盒，月底差异率高达8%。改为原子单位后，差异降到0.2%。设计检查点：数据库中的库存数量字段必须统一为一个小数位数精度（如6位），且所有计算都基于该字段。建议在配置界面强制要求选择“库存默认单位”，并禁止业务单据直接修改该字段的换算方式。
实操上，可以写一个存储过程定期校验：各业务表的原始单位数量换算成库存单位后，与库存表数量是否一致，误差超过0.001则告警。
我们系统里1箱=12个，但1个可能存在小数（比如0.0833箱）。每次出入库后，库存数量的尾数就会累积误差，比如本来应该是100箱，结果系统显示99.98箱。财务查账时说我贪污了0.02箱。怎么才能让精度问题不成为脏数据的源头？
精度问题本质上是“存储精度”与“展示精度”的博弈。很多系统只保留2位小数，一换算就丢精度。核心全局策略：存储采用高精度（比如6位或8位），展示保留业务习惯的精度（如2位），并在对账时以存储值为主。更关键的是要处理“舍入差额”。以1箱=12个为例：采购100箱=1200个。
如果销售1个，库存减少1个，换算成箱就是0.083333…箱。如果系统每笔都四舍五入到2位小数，第一次0.08箱，第二次0.08箱……12次后就只有0.96箱，而实际应减少1箱，这就是0.04箱的误差。
解决方案有两个：①使用“累计舍入法”：每次换算不直接取当前舍入值，而是记录累计应扣数量与实扣数量的差值，在下一笔中补回。②使用“最小单位优先”：在库存台账中直接以原子单位（个）存储数量，显示时再换算，彻底避免中间换算。
我们实测过，对一家月交易10万笔的零售企业，方案①能将月时点误差从2.3%降到0.01%以下。方案二更干净但需要前端展示时做换算（性能压力大）。具体代码实现上，建议在换算函数中增加一个全局静态变量记录当前会话的舍入误差累计，每次计算时先加上误差再取整。
配置上，建议提供“全精度计算开关”和“显示精度下拉”。我给出的最佳实践：存储精度=显示精度+2，比如显示2位则存储4位；每日运行一个定时任务，自动修正因舍入导致的库存差异（冲入一个“精度调整单”），并在报表中透明显示。这样财务看到的数字永远是整数，背后的精度差异由系统自动消化，从未有人投诉过。
读者评论
作为做了7年ERP实施的老兵，这篇文章戳到了我最疼的地方。我们项目也出过类似的事，采购按吨、仓库按箱、财务按公斤，结果月末库存金额差20多万。后来发现是基准单位没统一，每个部门各自维护主数据。文里说的‘单位组级别定义基准单位’这条，如果能早看到，能省不少返工成本。强烈建议所有项目在调研阶段就追问那三个问题，尤其是换算率因批次变化的情况。
财务视角看这篇，简直是救命。我们公司就经常因为多单位换算导致月末对账差几毛几分，审计每次都拿这个说事。文中关于‘精度不是技术问题而是管理问题’的观点太对了，系统必须允许按场景配置小数位策略，而不是一刀切。另外，批次级换算率存储那张表的思路很实用，以后被问历史成本依据，直接查映射表就够了。
作为一个写过库存模块的后端，看到文章里贴的数据库SQL和四条冗余字段建议，马上转给同事了。之前在单据查询时实时算换算率，果然踩过坑，有人改了主数据换算率，历史单据集体变样。文中强调‘base_qty必须在提交时写入而非审核时’，这个设计原则很硬核。还有浮动换算那条铁律，后端不该自动重算，之前没意识到这一点，感谢指出来。