一、项目背景

这个项目的客户是华东一家做建筑钢材和板材加工配送的区域贸易商，年流水十几个亿，下游客户结构挺杂：工地项目部、机械制造厂，还有一批自己开小加工点的个体户。我们最早接触是因为对方财务总监在一次会上摊了牌，上一年度结算差异挂账积到七百多万，跨了三个季度都没清干净。

钱不是没有，是账说不清。

他们的订单几乎全靠业务员微信接，一句"螺纹三级12的来八十吨，周四送工地"，业务员记在本子上，晚上再补录进那套用了八年的进销存。钢材有个绕不开的特点，理论计重（按国标米重乘以数量算出来）和过磅实际重量天然对不上，同一批货差个百分之一二很正常。行业惯例是分品类在合同里约定按理计还是按实计，可执行的时候业务员一句话就能改，磅单又是磅房手写完拍照发到微信群，月底对账全靠翻聊天记录，翻不到就各让一步。

加工那块更麻烦。开平、剪切、折弯这些工序有的按吨收费，有的按刀数收，损耗算谁的、余料归谁，全凭下单时口头讲。我看过一张单，客户认定余料该退，车间已经当废钢处理掉了，最后老板自己贴钱平事。

我们接手时定的目标很朴素：订单必须进系统，磅单必须不可改，结算必须按规则自动算出来。

二、落地场景

主体基于新普 S2B2C 供应链平台改造，跑通之后是五段串起来的链路。

在线报价与锁价下单。钢价一天一变，有时候上午下午两个价。我们把牌价改成"基价 + 品类升贴水 + 客户等级折让"的组合，业务员在小程序上生成报价单，客户点确认那一刻锁价，锁价时效可配，默认四小时，超时自动作废重报。这一步把口头议价变成了有时间戳的动作。

加工工单。下单时如果勾了加工项，系统会按品类和工序自动带出损耗系数和计费方式，余料归属做成必填的单选项，不选不让提交。工单推到车间的平板上，师傅扫码开工、扫码报完工。

过磅与磅单回传。磅房那台地磅原来是纯机械读数，我们加了一个采集盒对接串口，重量数据直接进系统，同时抓一张摄像头照片存证。司机在磅房拿到的小票上有二维码，扫码能看到这一车的品名、车号、毛皮净重和对应订单。

差异结算。这是核心。系统按合同约定的计价口径生成应收，同时把理计和实计两个数都摆出来，差异超过阈值的自动挂"待确认"，推给客服跟客户核。低于阈值的直接过账。

账期与授信。老客户有额度，下单时实时校验可用额度，超了走审批。这块沿用了平台原有的信用白条能力，没做太多改造。

三、关键技术挑战与解决思路

理计实计双口径，不能只留一个数。 一开始我们想简化，让客户在合同里二选一，系统只算一个。推行两周就顶不住了，因为同一个客户不同品类习惯不一样，板材要过磅，型材按理计，还有的客户是"以低者为准"。最后改成订单行级别存两套重量，计价口径下沉到品类维度配置，结算时按规则取数。数据库上多了一张 settle_rule 表，按 customer_id + category_code 做匹配，命中不到就走客户默认，再兜底走公司默认。

磅单防篡改。 客户对这个最敏感。我们的做法不复杂：采集盒读到的原始重量写入后就置为只读，任何修正必须走"磅单调整单"，单独一条记录，必须填原因、必须有主管审批，原始值永远留着。调整单的数量后来成了一个管理指标，某个磅房一个月调了四十多次，一查是设备零点漂移，顺手把地磅校准周期从半年改成了季度。

加工损耗与余料。 这块技术含量不高，难在把行规固化成参数。我们跟车间主任坐了两个下午，把十几种常见工序的损耗区间抄下来，做成上下限。实际报完工的损耗超出上限就报警，连续三次超限自动挂起该工序的接单。上线第一个月抓出一个师傅长期虚报损耗，多出来的料私下卖了，这事我们事先真没想到。

价格波动下的锁价时效。 锁价四小时听着合理，实操中出过一次事。某天早盘期货跳水，业务员集中在半小时内给几十个客户发了锁价单，客户当然都不急着确认，等到下午价格更低了才回来点确认，但系统还在有效期内，直接成交，公司当天亏了小二十万。后来加了一条：单日同一业务员锁价单总吨位超过阈值时，锁价时效自动压缩到一小时，并且给风控推消息。规则土，但管用。

案例片段（已脱敏）：某品类计价规则配置与差异判定逻辑

yaml settle_rule:  - customer_id: "C-2087"    category_code: "HRC_板卷"    price_basis: "actual"        # 实计    diff_threshold_pct: 0.8      # 差异超 0.8% 挂待确认    rounding: "0.001t"  - customer_id: "C-2087"    category_code: "REBAR_螺纹"    price_basis: "theory"        # 理计    diff_threshold_pct: 1.5

结算日志（节选）：[2025-xx-xx 23:12:04] SO-449213 line3 theory=80.240t actual=79.612t  diff=-0.628t (-0.78%) basis=actual threshold=0.80% -> AUTO_PASS [2025-xx-xx 23:12:04] SO-449213 line5 theory=25.000t actual=24.410t  diff=-0.590t (-2.36%) basis=theory threshold=1.50% -> HOLD_FOR_CONFIRM

案例片段（已脱敏）：磅单调整单审计记录

WB-20251103-0087  原始净重 32.180t  调整后 32.460t  差 +0.280t 原因：地磅未回零，司机下车后二次称重 提交：磅房-李  审批：调度主管-王  附件：磅房摄像头快照 2 张 该磅房当月调整 41 次，触发设备校准工单 EQ-0392

四、效果数据

系统全量切换跑了四个多月，几个数看下来还算实在。

结算差异挂账笔数从月均一百四十多笔降到二十笔上下，金额口径上，季度末未清差异从七百多万降到不足九十万，剩下的基本是真有争议的老单。对账周期是感受最明显的，原来财务月结要拖到次月十号以后，现在次月三号就能出，中间省掉的主要是翻聊天记录和打电话核数的时间。

订单在线率从不到两成提到九成一，剩下那一成是零星散客现款现货，业务员懒得录，我们也没强推。加工工单准时交付率从七成六提到九成三，主要收益来自工单可视化，调度能看到每台设备排了多少活，不再是靠喊。

磅单调整率稳定在千分之四左右，比上线初期的百分之一点二降了不少，一部分是设备校准的功劳，一部分是有人盯着以后就没人乱调了。

授信这块顺带收了个红利，超额度下单被拦下来的单子累计三百多笔，其中十几笔后来确实出了回款问题，等于提前避了雷。

文中数据为项目复盘口径，已做脱敏处理。

五、可复用经验总结

做钢贸这类大宗商品的线上化，最容易踩的坑是把它当普通电商做。普通电商一个 SKU 一个价，钢材是一个 SKU 一天几个价，还要按吨算、按米算、按支算，重量口径本身就是要谈的东西。系统设计上如果不在第一天就把"多口径共存"作为前提，后面全是补丁。我们这个项目在双口径上返工过一次，损失了大概三周。

磅单这种物理世界的数据，最好的办法是让它一次性写死，改动走另一条路留痕。这跟做技术审计是一个道理，你不用禁止修改，只要让每次修改都被看见，人的行为自然就变了。地磅校准周期那件事，是我们看调整单统计才发现的，本来完全不在项目范围内。

行规参数化这件事，别指望自己能想全，找车间和磅房的老师傅聊，他们脑子里那套上下限比任何文档都准。我们前期花了两个下午做这个，回头看是整个项目性价比最高的两个下午。

锁价那次亏损，说到底是规则设计时只考虑了正常场景，没考虑有人会等着占便宜。后来我在别的项目里养成了个习惯，任何带时效的商务规则，都要问一句"如果对方故意拖到最后一秒，我们亏不亏"。

眼下这套东西还在改，下一步要接的是期货套保数据，让锁价和套保头寸联动，这块业务方自己也还没想清楚，我们暂时不动。