事情是這個樣子的：項目在實施過程中，碰到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作為虛擬庫存也能正常加減庫存（正常情況下，虛擬庫存往外調撥不會消減庫存數量）。
