把銷售單的新字段傳遞給對應(yīng)的出庫單？

1.?基于下游結(jié)果二開

直接去改下游的create方法。

其中，stock.move是最簡單的，在sale_line_id的綁定關(guān)系下，直接取值賦值即可；

對于stock.picking而言稍稍有點麻煩，需要基于origin去進行模糊匹配。而origin往往 是在二開需求中出現(xiàn)頻率高頻的標志性字段，所以可能還需要去進行一些冗余的處理， 比如,split。

2.?增加一些上游的幫助

基于stock.picking面臨的潛在的麻煩，使用上下文，由上游sale.order傳遞，下游 stock.picking捕獲顯然更為合適一些。

3.?在上游入口處進行同步

在sale.order.line的_action_launch_stock_rule，super完后，給下游單據(jù)同步一下新字段。

4.?順應(yīng)源碼的增量開發(fā)

無非就是關(guān)注一下sale.order.line的_prepare_procurement_group_vals， _prepare_procurement_values，同時再為對應(yīng)的模型提供數(shù)據(jù)支持。

?

其實，這不僅是個非常高頻的二開需求，同時也常常作為開發(fā)案例被反復(fù)提及。

如果不考慮代碼分布、維護成本等一系列現(xiàn)實問題，可能沒有人能抵擋最后一個方案的誘惑（至少在我這兒）?；谠创a業(yè)務(wù)邏輯的二開必然會帶來更少的BUG，也更不容易與其他二開模塊起沖突，此外，還有更重要的理由。

然而即便如此，那種一時的滿（you）足（yue）感卻并不是“好”代碼的保障。物美的同時，價廉也很重要。

現(xiàn)在讓我們來重新審視一下最后一個方案的二開思路。以_prepare_procurement_values為例：

????????def _prepare_procurement_values(self, group_id=False):

????????????values = super()._prepare_procurement_values(group_id=group_id)

????????????values[''] = ''

????????????return values

其實這里面體現(xiàn)了一個有點奇怪的邏輯，即在那一刻起，這個我們需要傳遞的新字段與sale_line_id屬于平行關(guān)系；然而從數(shù)據(jù)結(jié)構(gòu)中其實這兩者處于從屬關(guān)系。

換句話說，看起來這個方法更適合一個以更復(fù)雜的應(yīng)用場景，例如：

????????def _prepare_procurement_values(self, group_id=False):

????????????values = super()._prepare_procurement_values(group_id=group_id)

????????????values['']?= self.order_id.partner_id._get_remark(self.product_id, self.product_uom_qty)

????????????return values

諸如此類體現(xiàn)一個動態(tài)過程，而不是一個靜態(tài)的值。

殺雞焉用牛刀？

?

本想就此結(jié)尾，然而我果然還是經(jīng)不住自己另一套說辭的反復(fù)攻勢。有沒有這樣一種可能，在設(shè)計之初，跨模型的數(shù)據(jù)傳遞之間，stock.move就屬于一個只讀的業(yè)務(wù)模型呢？有沒有這樣一種可能，有且只有env['procurement.group'].Procurement參與其中，由此產(chǎn)生的stock.move才是“真”有效合法呢？

?

我得不出結(jié)論。但我知道，這種可能一定是有的。