一、留库单的使用场景

留库单功能和批销单比较类似，应用的场景主要是不方便开批销单，但是又需要把库存留住，避免在发货的时候没有库存的困境。某些批发量很大的客户，开批销单就意味着拣货和装车、发货。如果每张单据都要做这种动作，效率就会比较低。所以客户通常都是累积了一定数量的单据以后，再进行这种动作，因此留库单就应运而生。

二、旧版本留库单的实现方式和优缺点

旧版本的留库单其实是生成调拨单，留库的时候，会把库存从当前的仓库调拨到一个叫“留库仓”的虚拟仓，这个仓库对于业务单据是不可见的，也就是开单时候无法从“留库仓”开单，也就是说，库存进入“留库仓”以后，除了通过留库单，就不能再操作这些库存了，从而达到留库的目的。

留库单释放库存有两种方式：作废留库单和生成批销单。这两种方式都会把库存从“留库仓”调拨到原来的调出仓。作废留库单，调拨结束以后，就完成操作了。生成批销单在调拨结束以后，马上利用这些库存开批销单。

这种留库方式在整个过程总库存是没有任何变化的，因为调拨不影响总库存，对于现存的大量和库存有关的报表是一大喜讯，因为无需任何修改。但是有个问题就是留库单的开单性能存在着浪费，因为留库的时候，除了要做留库的一些动作以外，还要做一次完整的调拨动作，中间的过程复杂而漫长。在数据量比较少的情况下，可能感觉不明显；但是一旦数据量比较大的时候系统响应就会比价缓慢。最可怕的问题是，如果遇到死锁或者连接中断，库存可能就会永久留在“留库仓”无法再利用。

从希扬那边的应用情况看来，留库单引发死锁的频率还是非常高的。这里就引出了一个矛盾的问题。为了保证数据完整，留库时只好使用事务的形式，否则一旦出错，就无法恢复了；但是用了事务以后，由于事务里面的操作过程比较长，所以很容易引发死锁，要解决问题最好就是放弃事务的方式……

最可怕的是，数据一旦出错，有时候是不可逆的，连重算都没法获取正确的数据，这是客户完全不能接受的糟糕状况。

三、新版本的留库单

解决留库单死锁和数据容易出错的问题，归根究底就是要缩短留库时的操作过程，减少影响的数据表。因此新版本的留库单改为不再利用调拨单，而是直接扣减库存，整个过程和开批销单差不多，区别就是开留库单的时候不马上扣减库存，而是在“留库”操作以后再扣减库存。修改以后，大大减轻了原来死锁和数据出错的问题，就算是数据出错，都可以通过重算来获取正确的数据。唯一的缺点就是会影响总库存，如果对于总库存很敏感的客户，就需要在统计分析的时候注意统计留库单。

新版本的留库仓整个开单过程和批销单雷同，对于熟悉批销单操作的操作员来说是很容易上手的。由于只有留库单一种单据，出错以后问题也比较容易发现。

四、一个容易忽略的单据业务选项

在这里提醒下，留库单的业务设置，是沿用批销单的，所以没有单独的设置项目。在单据业务设置的“批销单”选项里面，有个“批销时是否要扣减未留库的留库单的数量”的设置，该设置是控制在开批销单（留库单）时候，可用库存是多少。如果勾选了，那么有效留库单占用的库存就不能使用。有效的留库单就是没有作废以及没有生成批销单的，至于“已留库”和“已生成批销单的留库单”，实际占用的库存已经导致库存发生修改，因此不能再考虑。举个例子说明下：

某仓某本书库存为50，有A、B、C三个留库单，三单的数据涉及该书的数据均为30，A是新开的留库单，还没有留库；B是已经作废的；C是已经生成批销单的。那么开批销单时，可用库存是多少呢？无论是否勾选“批销时是否要扣减未留库的留库单的数量”这个设置项目，B和C单的数量对于库存都是没有影响的，因为这两单的库存变化已经反映到真实库存里面了，因此计算可用库存的时候无须考虑BC单。

至于A，如果没有勾选项目的时候，也就是不考虑留库单占用的库存，那么当前可用的库存就是50；如果勾选了，那么实际的可用库存就是50-30=20。

（摘自广智内部博客）