这一份是谁写的：由 HEYI 撰写，介绍我们交付的一个客户项目。客户名称已按其要求匿名处理，量化数据由客户提供，每一项的口径写在文末「口径与说明」里。
这一份里有什么
- 客户的业务链路：从入库登记到月末对账
- 五件挡在前面的事，其中两件是硬约束
- 六条方案，关键那一条是「锁货不扣库存」
- 对账 3 天 → 10 分钟，客户的习惯没动
- 每一个数字的口径与出处
01 场景
货存在客户仓库里，经销商要提货，得先确认这批货现在能不能订。
客户是国内一家第三方物流企业，为国际品牌车用润滑油品提供仓储代管服务。货主的下游经销商需要提货时，先得有人回答一个问题：这批货现在能不能订。
这条链路上的五个环节，系统全都管，上一步的结果直接进下一步。交付是双端应用：前台给客户与业务员提交订货咨询、查询历史；后台给内部人员做基础数据维护、入库登记、发货结转，以及月度进出库明细的导出。
- 入库登记：货主的货进仓，登记数量与批次。
- 订货咨询：实时判定能不能订，只算不写、不占库存。
- 确认锁货：客户确认后把货锁住，库存一分不动。
- 发货结转：管理员确认实际发出，库存这时才真正扣减。
- 月末对账：导出进出库明细，与货主核对当月账。
五个环节按业务顺序自上而下读。库存只在第四步扣减——后面的设计都是从这一条推出来的。
02 挑战
手工台账上只有「结存」一个数字，已经答应出去、货还没发的那部分，系统里没地方记。
01 库存的三个量，手工台账里只剩一个
手工表上只有「结存」。已经答应经销商、但货还没发出去的量，没有任何地方可以记——它只存在于业务员的记忆和聊天记录里。多个经销商同时问同一款货，超卖和重复承诺挡不住，出了问题也没法复盘。
02 对账表铺到 94 列，而对账习惯不能动
客户在用的月度《进出库明细》，单月横向铺到 94 列：列结构按当月实际发生业务的日期动态展开，每个日期块由「入库 + 各收货单位出库 + 结存」组成，结存列是逐块累加的 Excel 公式，还叠加期初结存列、按品类合并的单元格、表头冻结与自动筛选。这张表是给货主看的对账凭证——版式必须一模一样，不能因为上了系统就让客户改对账习惯。
03 经销商的订货单，一家一个样
各家发来的订货 Excel 表结构各异，收货单位的写法常常跨几个单元格、混着地址和电话。人工逐单录入不仅慢，还容易错行错列，而错一个数量就是一次发货事故。
04 跨月未发货订单的账务口径含糊
一笔已锁货但还没发货的订单，在结转之前会连续出现在几个月的报表上。这算重复计算，还是必要的风险提醒？口径不定清楚，报表就永远对不上。
05 期初结存不能「想当然」
「查不到数据」和「期初确实为 0」是两件不同的事。把数据缺失显示成 0，等于向货主错报「这款货没有库存」——比留空危险。
一个月的对账表，94 列。这张图不区分列的类型，要看的就是它有多密——它是人工维护的，含累加公式与合并单元格，每月一次。
03 方案
把库存拆成三个量，「承诺」和「事实」分开记；那 94 列由系统原样生成。
01 先把业务讲清楚：库存的三个量
关键决定是锁货不扣库存。货没真正出库前，实际库存一分不动，变小的只是「可用结余」；只有管理员确认这批货确实发走了，库存才真正扣减。这一条把「承诺」与「事实」分开——超卖问题从此有数据可依，不靠人盯。
02 订货咨询做成两步：先预演，再确认
第一步只算不写、不占库存，客户先看到逐个商品能不能订；第二步才确认锁货。判定采用整批全有或全无：只要有一个商品不足，整批不可订、一件都不锁，避免半单成交带来的后续纠纷。无论通过与否，每次咨询全程留痕、可追溯。
03 订货单直传，规则 + AI 两层解析
按客户预先配置解析规则——去哪读收货单位、商品编号从哪开始、数量列在哪、读到哪停、空值怎么算，一家一套，配一次长期用。AI 负责收货单位的语义匹配，把跨格、带地址电话的各种写法匹配到系统里已有的单位并给出置信度；模型出问题时自动降级，不阻断业务。匹配不上的商品行会显式回传提示，由人确认，系统不替业务做假设，也不会悄悄跳过。
04 发货结转：一个动作完成三件事
管理员按批次或按商品勾选本次实际发出的货，系统在一个事务内完成锁货转发货、库存实扣、生成快照。结转截止线设在「本月 1 日」，与月度对账周期严格对齐——本月发出的货留在本月报表里。
05 报表原样复刻手工台账
系统按当月实际业务日期动态生成日期块列、写入可追算的 Excel 累加公式、按品类合并单元格、冻结表头并挂好自动筛选，跨月未发货订单单独成块。客户拿到的文件，与他们手工做了多年的那张表版式一致——不用学，也不用改对账习惯。账务口径同时定清：已结转的量由期初结存承载，未结转的量作为当期出库列出，两者不重复计算。
06 每一笔库存变动都留痕
入库、发货结转、人工调整——所有能改库存的入口都留下可追溯的流水。人工改结存会自动生成「库存调整 100 → 130」这样的快照，既留证据，也让报表期初跟着更新。
- 库存 （结存）：仓库里实际有多少货
- 冻结：已答应经销商、还没发货
- 可用结余：还能接多少新订单
可用结余 = 库存 − 冻结。锁货只让可用结余变小，库存要等发货结转才动。
三个量的关系。原先手工台账上只有最上面那一条，中间那条只在业务员脑子里，最下面那条因此也算不出来。
04 成果
月末对账从 3 天压到 10 分钟，而客户的对账习惯一点没改。
- 上线前 · 月末对账：3 天——人工维护 94 列、含累加公式与合并单元格的 Excel
- 上线后 · 月末对账：10 分钟——选客户 → 一键导出，版式与手工那张表一致
数据由客户提供，口径见文末「口径与说明」。
01 效率
月均处理约 3000 笔订货咨询，日常业务全量在系统内运转。90% 以上的订货录入由 Excel 直传自动完成，人工逐单敲键盘从主流程退成了例外处理。
02 风险
可用结余实时判定、整批全有或全无、锁货全程留痕，「谁在什么时候占了多少货」可以追到单条记录。对账争议也有据可查：三个量的每一次变动都有流水与快照，月度数字能逐笔回溯到业务凭证。
03 体验
客户那边什么都不用改——报表版式与原手工台账一致，货主端的对账流程完全不用变。业务侧上手快：前台三步提交咨询，或者直接把经销商发来的 Excel 拖进来。
04 稳定性与交付规模
上线后稳定运行 2 个月，订货咨询、入库登记、发货结转、月末对账已全量在系统内运转。交付体量供参考：约 8700 行前后端代码、46 个业务接口、9 张业务数据表、双端两套界面。
把「货在谁手上、还能卖多少、这个月发了多少」这三个原本只在业务员脑子里的问题，变成系统里查得到、每一笔都能往回追的数据。
而客户的对账习惯，一条都没改。
口径与说明
- 客户身份：客户名称按其要求匿名，行业与业务场景如实描述。
- 量化数据：3 天 → 10 分钟、月均约 3000 笔订货咨询、90% 以上自动录入，由客户提供；统计区间为系统上线后的运行期。
- 「稳定运行 2 个月」指截至本文写作时（2026 年 9 月）的运行时长，会随时间变化，引用时请向我们确认最新值。
- 94 列指客户原有月度《进出库明细》单月的横向列数；列数随当月实际发生业务的日期变化，94 是客户提供的实际样本。
- 交付规模（约 8700 行代码、46 个接口、9 张表）来自交付时的代码与接口清单，用于判断项目体量，不作为工作量或报价依据。
- 关于界面截图：系统界面含客户商品与经销商信息，本文未使用截图。需要看界面时，我们用演示数据现场演示。
关于这个案例的常见问题
这个系统能处理我们复杂的对账表格吗？
可以。系统按客户原有月度《进出库明细》的94列结构动态生成，包含累加公式与合并单元格，版式与手工表一致，客户无需改变对账习惯。
系统如何确保不会超卖？
通过'锁货不扣库存'机制。系统将库存拆分为'库存'、'冻结'和'可用结余'三个量，锁货只减少可用结余，不减少实际库存，直到发货结转才真正扣减。
对账时间真的能从3天缩短到10分钟吗？这个数据怎么统计的？
能。数据由客户提供，统计区间为系统上线后的运行期。客户从人工维护94列Excel表格耗时3天，改为系统一键导出耗时10分钟，报表版式与原手工表一致。
系统有什么做不到的地方？
系统不替业务做假设，也不会悄悄跳过问题。当AI无法匹配收货单位时，会显式提示由人确认；模型出问题时自动降级，不阻断业务。对于无法匹配的订货单，需要人工介入处理。
90%的自动录入准确率是怎么保证的？
通过预先配置的解析规则和AI语义匹配双重保障。规则负责定位数据位置，AI负责处理收货单位的语义匹配，匹配不上的会显式提示。数据由客户提供，统计区间为系统上线后的运行期。