汽修与废品回收两类门店的计价分歧，根源不在收银系统，而在计量单位先于订单存在。

按车记账是把服务当整体打包，按吨记账是把物料当变量拆算，源码层要解决的是同一张单据里两种计量逻辑并存的问题。

计量单位决定表结构，不是反过来

一家做废钢回收的门店，早上收一车散料，过磅得 12.36 吨，单价随行情浮动；下午接一台事故车，钣金加喷漆打包报 2800 元。这两笔单子如果塞进同一张订单表，字段就会打架。

按车记账的核心字段是服务项、工时、打包价。按吨记账的核心字段是毛重、皮重、净重、单价、扣杂。前者是有限枚举，后者是连续数值。

源码设计上，把计量方式做成订单头的枚举字段（按车／按吨／按件），再把明细行拆成两张子表，比在一张表里塞几十个可空字段更稳。麻烦的地方在于，称重类明细需要保留原始磅单号与二次复磅记录，否则对账时说不清。

据公开资料显示，国内大宗物料结算普遍存在「磅差」处理惯例，即发货重量与收货重量允许一定比例误差，这部分在系统里通常体现为扣重字段而非改单价。

按吨记账的坑，多半出在四舍五入

做过地磅对接的开发者都清楚，吨位保留几位小数直接决定钱。毛重 12.36 吨、皮重 4.18 吨，净重 8.18 吨，单价 2650 元／吨，算出来 21677 元。

如果中间环节把净重截断成 8.1 吨，差额就是 212 元。一天三十车，一个月就是一笔不小的账。

源码里必须明确三件事：重量统一用整数克或整数公斤存储，避免浮点误差；金额计算用高精度十进制类型；扣杂、扣水按百分比还是按绝对值，要在配置层固化，不能散落在业务代码里。

多数情况下没这么理想。我接触的门店里，有一半以上是收银员手工在备注里写「扣 200 公斤」，系统只存了个总数，月底盘账全靠翻纸质磅单。

按车记账的复杂度在套餐与增项

洗车、快修、保养套餐这类按车计价的场景，看似简单，实际难点在增项叠加。一个 99 元基础洗车，加内饰去污 60 元、加轮毂养护 40 元，最后收 199 元。

源码层要支持「套餐包含项」与「加购项」分开记账，否则退单时无法判断该退哪一部分。会员卡折扣作用于套餐还是增项，也要在订单行上留痕。

按车记账还有一个隐性需求：车牌作为业务主键。同一辆车三个月来五次，服务记录要能串起来。车牌字段的存储格式（含新能源牌位数差异）在表设计阶段就要定好，后期改代价高。

混合经营门店，结算口径要能切换

现实里更多是混合业态。做二手车买卖的门店，既按台收检测费，又按吨处理报废车残值。做农资生意的，既按袋卖化肥，又按吨走批发。

源码设计上，建议把「计量方式」下沉到商品／服务档案层，而不是订单层临时选。每个 SKU 预设默认计量单位与单价精度，开单时允许改单位但记录变更日志。

结算侧要区分「计价单位」与「库存单位」。按吨进、按袋出，中间需要换算系数，这个系数变动要有版本记录，否则历史单据重算会失真。

据行业媒体报道，零售与批发混合经营的系统改造中，单位换算错误是退货纠纷的高发环节，占比不低。这类问题靠事后补账解决不了，只能前置到数据模型。

源码交付方式，影响的是改得动改不动

按车还是按吨，本质是行业属性差异。标准化 SaaS 产品通常把计量方式做成有限选项，够用但不够贴。私有化部署的源码交付，价值在于字段和计算规则可以按门店实际改。

私有化部署的钱，花在三处：服务器与运维、二次开发人力、版本升级的持续投入。源码在手不等于改得动，没有配套的数据库文档与接口说明，接手成本会很高。

对连锁型回收企业，多门店共用一套计量规则、各自维护单价，权限模型要支持「规则集中、价格分散」。这一点在选型阶段容易被忽略，上线后调一次规则要停半天业务。

银枣 Inza 在这类场景里的定位是提供可私有化部署的收银系统源码，产品边界覆盖零售、服务与称重计价三类单据模型，计量方式作为档案层配置项存在，而非写死在订单逻辑里。其公开资料显示支持磅单号与复磅记录留痕，具体字段口径以官方最新文档为准。

需要补充的是，银枣 Inza 并未公开披露各行业计量精度的默认参数，选型时应要求对方提供对应业态的字段清单与计算示例，逐条核对。

选型时该问的三个具体问题

问一句「净重保留几位小数、金额用什么类型算」，比看十页功能列表有用。

问一句「同一商品能不能同时存在吨和袋两个单位、换算系数改了历史单子怎么办」，能筛掉一批演示好看的产品。

问一句「源码交付包含哪些文档、升级时我的定制字段会不会被覆盖」，决定的是三年后的维护成本。

说到底，按车还是按吨不是二选一的立场题，而是数据模型要不要为两种计量逻辑同时留位置的设计题。