事情是这个样子的:项目在实施过程中,碰到A仓库向B仓库供货的情况,心想这还不简单,老老实实地建多个仓库并将B仓库的供货仓库选为A仓库,再设置好产品的再订购规则,万事大吉了。然而,事情并非想象的那么简单,同一产品B仓库的管理员做了两次出库,一次100,一次200,间隔几分钟,系统MRP运算设置的时间是1分钟,在A仓库形成的出库单中2个产品并没有合并。A仓库管理员不乐意了,同一个产品怎么能在同一张出库单上出现多次呢?强烈要求将同一张出库单的产品数量合并到一起去。好吧,合并就合并吧,原本以为工作量不大的改动,却着实费了老大劲,这里边牵扯到Odoo的拉式库存机制的实现,下面我就浅析一下Odoo拉式库存的实现机制。

首先,B仓库缺少的产品由A仓库进行供货,这里起作用的是产品设置在B仓库的最小订购点,最小订购点会生成一张需求单(Procurement Order)PO1,这张需求单的规则被设置为Transit Location->B 仓库库位,系统会根据此规则创建一条库存移动(Stock Move)M1,该Move的procurement_id会被设置为了PO1。因为Transit Location->B 的规则的procurement_method为make_to_order,系统在assgin该Move的assign的时候会创建一个新的procurment order PO2,这个新创建的procurement order与之前一个不同的地方在它的move_dest_id被设置为了M1,move_dest_id和move_orig_ids是stock move对象用来关联移动链(chain)的字段,move_dest_id指下一步的move,move_orig_ids则指上一步过来的moves。当PO2运行之后,会根据规则创建一条由A仓库到 Transit Location的Move(M2),M2的move_dest_id将会根据PO2的move_dest_id设置为M1,同时,M2也会被添加到M1的move_orig_ids列表中,这样M2就成为了M1的上游Move,M2,M1形成了链条。这也就解释了为什么TransitLocation作为虚拟库存也能正常加减库存(正常情况下,虚拟库存往外调拨不会消减库存数量)。