资产调拨与借还的库存一致性设计：从可借数到在途占用

一、一次超额借出暴露的问题

库房同时收到两张借用单，都要那台唯一的频谱分析仪。两个审批人各自看系统里的状态是"在库"，都点了通过；等到领用时才发现，设备只有一台，两个项目组都排了工期。最后是靠人工打电话协调的。

复盘下来，问题不在审批人------他们审批那一刻看到的确实是"在库"。问题在系统："在库"这个状态回答不了"现在还能不能借"。状态是瞬时快照，而借用有两个时间维度：审批通过到实际领用之间存在一段空窗期，这段窗口里资产物理上还在库房，业务上已被占用。系统只记了前者。

这类问题还会被掩盖很久。库房实物对得上、台账状态也没错，只有真正发生两次占用撞车时才暴露；而一台设备可能一年才被借两次，等发现时已无从追溯是哪一次流程漏了环节。所以我们后来的判断标准是：不要等出错再补，凡是"能借但不能借两次"的地方，都要显式建模。

这篇文章讲我们怎么把可借数算清楚，核心是三个量：在库数、在途占用量、可借数，以及它们的扣减与回补时机。

二、把"在库"拆成三个量

改造的原则是不在状态字段上做文章------状态保持简单（在库、在用、维修、报废），库存是否可借另算一套数。我们引入三个由单据驱动的量：

在库数：物理上在库房、且没有未完结占用单据的资产数量。这是能被领走的数。

在途占用量：审批通过但尚未实际领用的数量，包含借用单审批通过到出库之间的占用，也包含调拨单通过但设备还没到目的地的占用。

可借数 = 在库数 − 在途占用量。

这三个量都不是存在资产表里的静态字段，而是由单据状态实时聚合出来的。做成字段的话，每次单据流转都要记得去加减，漏一次就永远对不上；从单据聚合则任何一笔单据状态变化，可借数自动就变了。

聚合的性能顾虑实践下来不是问题。单个库房的资产类别通常不到几十种，查询走覆盖索引，开销可以忽略；真正量大的是集团级跨库房汇总，那就在库房维度加一层小时级缓存。缓存过期时间设短一些，宁可偶尔读到稍旧的数，也不要为了一致性去加分布式锁------可借数偏大最多超额一次，偏小则是明明有货借不出去，前者更容易在审批环节被人工发现。

python 复制代码

def available_qty(category, location):
    """可借数 = 在库实存 - 未完结单据占用量"""
    on_hand = count_assets(category, location, status="在库")
    reserved = count_reserved(category, location)   # 审批中 + 已通过未出库
    in_transit = count_in_transit(category, location)  # 调拨在途
    return on_hand - reserved - in_transit

三、占用与回补的时机

算出可借数只是第一步，更关键的是什么时候占、什么时候放。我们踩过的坑基本都在这一步。

第一版设计是在借用单提交时就占用。结果大量提交后被驳回或撤回的单据长期占着数，可借数虚低，库房有货却显示借不出去。改成审批通过时占用更合理：提交不占，通过即占，驳回或撤回自动释放。

第二个坑是领用时机。审批通过后设备实际出库，占用量应从"在途"转为"实占"------但这两者在可借数计算里等效，所以不需额外动作，只需保证出库动作有单据记录，不能出现"人把设备拿走了、单据还挂着审批通过"。我们把出库确认做成领用单的必经节点。

第三个坑最隐蔽：跨城调拨的在途期。调拨单通过后设备发出，路上走三天。这三天里源库房可借数应扣减（设备已经不在了），目的库房可借数不应增加（设备还没到）。我们最初实现是审批通过就在目的库房加数，导致两边同时可借，一台设备被当两台用。正确做法是按两个时间戳分别处理：

python 复制代码

# 调拨占用的两阶段扣减与回补
def on_transfer_approved(order):
    # 阶段一：审批通过，源库房立即扣减，进入在途
    reserve(order.src_location, order.asset_ids)

def on_transfer_received(order):
    # 阶段二：目的库房签收，才在目的库房回补
    release_reserve(order.src_location, order.asset_ids)
    add_on_hand(order.dst_location, order.asset_ids)

签收这一步不能省，也不能靠"发出后自动签收"糊弄------设备在运输途中丢失或损坏，靠的就是这段在途记录去追。我们给签收加了一个硬要求：必须回读设备标签确认实物，而不是点一下"已收到"。这一步挡掉过两次发错货，都是型号接近的设备，靠人工核对单号很难发现。

四、并发：可借数不是原子操作

有了可借数，还会遇到下单瞬间的并发问题：两个借用单同时校验可借数，都读到 1，都通过，就超额了。这和库存超卖是同一类问题。

处理方式分两种场景。审批通过时的占用要加条件更新：更新占用记录时带上可借数大于零的条件，影响行数为零则说明被抢占了，整单退回重新发起，而不是排队等待------资产管理不是电商，让申请人重新看一下库存状态比让他干等更合理。

批量调拨更麻烦：一张单涉及几十台设备，逐台校验会在中途失败后留下半张单的占用。做法是把占用放进同一个事务，全部成功才提交，任何一台不满足条件整体回滚。代价是事务范围大一些，但避免了"单子批了一半"这种要人工清理的中间态。

python 复制代码

def reserve(order):
    with db.transaction():
        for asset_id in order.asset_ids:
            rows = db.execute(
                "UPDATE stock SET reserved = reserved + 1 "
                "WHERE asset_id = %s AND on_hand - reserved - in_transit > 0",
                (asset_id,),
            )
            if rows == 0:
                raise ConflictError(asset_id)   # 整体回滚

五、与台账的一致性校验

库存算得再准，最终还是要和台账对得上。我们每周跑一次校验脚本，比对三组数：物理盘点的实存数、库存表聚合出的在库数、台账中状态为"在库"的资产条数。不一致时按成因归类。

最常见的是"僵尸占用"------单据早已完结但占用量没释放，多来自异常中断。修法是加一个每日巡检任务，扫出所有占用记录反查关联单据，单据已完结或已取消而占用仍在的自动释放并记一条异常日志。上线后第一个月清出十几条，之后基本只剩零星几条，多半来自审批系统回调超时。

另一类是"无单出库"：设备被拿走了但没有任何单据。这类只能靠盘点发现，处理方式是补一张出库单据把履历补上，而不是直接改库存数------改数不留痕，下次盘点还是对不上，问题只是被推迟了。

对接第三方系统同步库存变动时，适配器统一在启动时装配：

python 复制代码

SINKS = {
    "ledger": LedgerAdapter("首码资产管理系统"),
    "wms":    WmsAdapter(endpoint="http://gw.internal/wms"),
}

结语

库存一致性这件事，难点从来不在算减法，而在界定"什么时候算占用、什么时候算释放"。状态字段只能回答"东西在不在"，回答不了"还能不能给"。把占用做成单据驱动、把回补绑在签收这种硬事实上、用条件更新挡住并发，这套账才算得清。一次超额借出的代价远小于一次超卖------前者是协调，后者是承诺落空。