自动锁库解锁服务在进行锁库逻辑处理时是会排除当前操作前已锁库数量的，即会使用当前数量减去已锁库数量 去锁库。举个例子，假设在发货通知单上配置了保存时锁库，当发货通知单第一次保存前明细里录的数量是10，那么第一次保存后就会锁库10个数量（这里前提是有库存可用量，且上游销售订单没有锁库，下文都假设此前提满足），后续操作时当客户认为数量10是错误时，客户可能会将数量10修改成15（数量由小变大），再次点保存时，这时的自动锁库解锁服务会判断第一次已锁库数量已经存在10个数量，现在的单据上的数量又是15，那么会再追加5个数量的锁库量，即最终会锁库成15个数量。但是当第二次修改如果数量是从10改成5（数量由大变小），此时自动锁库解锁服务看到前面已经锁库10个数量且大于当前单据数量，则什么也不做。这样保存后单据是5个数量，锁库却是10个数量。这种原因主要是发货通知单保存操作只配置了锁库（自动锁库解锁服务里的锁库/解锁类型字段为锁库），没有配置解锁，导致系统不知道何时解锁。针对这种情况，建议客户配置此服务时放在提交操作上（即提交时锁库，撤销时解锁），提交后一般是修改不了库存维度的，或者在保存操作时配置一个解锁和一个锁库（解锁在前，锁库在后）。

    针对上面这种在保存操作时先解锁后锁库的情况，虽然可以处理第二次保存数量由大变小的情况，但是它不能解决删除分录行的情况。假设客户第一次保存时有两条分录（假设为分录1和分录2），数量分别为10和20且两条分录都锁库了，当客户删除分录2再保存时，此时单据只有分录1，没有了分录2，因为保存操作是配置了先解锁再锁库，先解锁时查询不到分录2，只能解锁分录1，然后再锁库时只能锁分录1。这样就会导致第二次保存后即使删除了分录2，它的锁库信息还在。这种情况要在删除分录菜单下配置个解锁服务（此解锁服务挂在一个空操作上即可，不要在删除分录行操作上挂解锁），如下图1-1所示：

图1-1

    上图1-1中，一定要将解锁服务配置到所有删除分录操作前，如果配置在删除分录操作后，则会有问题，因为先删除分录再解锁会解锁不了，解锁服务配置配置如下图1-2所示：

图1-2

写在最后：

    总体来说不建议客户在单据保存时锁库，一般是建议在提交/撤销，审核/反审核，审核/作废等操作上成对地配置锁库/解锁。如果客户将锁库服务强制配置在单据的保存操作上时则一定要考虑好解锁的时机，通常要考虑删除分录行，数量改小，列表上删除单据等，这些动作一般都要解锁，另外就是配置先解锁后锁库或者在分录行配置解锁这种都是有性能损耗的(比如单据分录很多时，只删除一条分录，就解锁整个单据，再次保存时又锁库剩余的行，这种就可能存在性能损耗)，而且在删除分录行解锁时是会把删除分录行操作后就立即解锁，当删除分录行但不保存时，锁库信息是被清除了。

如果是在审核中被驳回，那么单据就不会有撤销、反审核等动作，那怎么解锁呢