一、留库单的使用场景

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


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

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

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

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

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

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


三、新版本的留库单

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

新版本的留库仓整个开单过程和批销单雷同,对于熟悉批销单操作的操作员?#27492;?#26159;很容?#21672;?#25163;的。由于只有留库单一种单据,出错以后问题也比较容易发现。


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

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

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

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


(摘自广智内部博客)