事情是这个样子的：项目在实施过程中，碰到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作为虚拟库存也能正常加减库存（正常情况下，虚拟库存往外调拨不会消减库存数量）。
