0O00--销售=>库存 同步新字段

把销售单的新字段传递给对应的出库单？

1. 基于下游结果二开

直接去改下游的create方法。

其中，stock.move是最简单的，在sale_line_id的绑定关系下，直接取值赋值即可；

对于stock.picking而言稍稍有点麻烦，需要基于origin去进行模糊匹配。而origin往往 是在二开需求中出现频率高频的标志性字段，所以可能还需要去进行一些冗余的处理， 比如,split。

2. 增加一些上游的帮助

基于stock.picking面临的潜在的麻烦，使用上下文，由上游sale.order传递，下游 stock.picking捕获显然更为合适一些。

3. 在上游入口处进行同步

在sale.order.line的_action_launch_stock_rule，super完后，给下游单据同步一下新字段。

4. 顺应源码的增量开发

无非就是关注一下sale.order.line的_prepare_procurement_group_vals， _prepare_procurement_values，同时再为对应的模型提供数据支持。

 

其实，这不仅是个非常高频的二开需求，同时也常常作为开发案例被反复提及。

如果不考虑代码分布、维护成本等一系列现实问题，可能没有人能抵挡最后一个方案的诱惑（至少在我这儿）。基于源码业务逻辑的二开必然会带来更少的BUG，也更不容易与其他二开模块起冲突，此外，还有更重要的理由。

然而即便如此，那种一时的满（you）足（yue）感却并不是“好”代码的保障。物美的同时，价廉也很重要。

现在让我们来重新审视一下最后一个方案的二开思路。以_prepare_procurement_values为例：

        def _prepare_procurement_values(self, group_id=False):

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

            values[''] = ''

            return values

其实这里面体现了一个有点奇怪的逻辑，即在那一刻起，这个我们需要传递的新字段与sale_line_id属于平行关系；然而从数据结构中其实这两者处于从属关系。

换句话说，看起来这个方法更适合一个以更复杂的应用场景，例如：

        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

诸如此类体现一个动态过程，而不是一个静态的值。

杀鸡焉用牛刀？

 

本想就此结尾，然而我果然还是经不住自己另一套说辞的反复攻势。有没有这样一种可能，在设计之初，跨模型的数据传递之间，stock.move就属于一个只读的业务模型呢？有没有这样一种可能，有且只有env['procurement.group'].Procurement参与其中，由此产生的stock.move才是“真”有效合法呢？

 

我得不出结论。但我知道，这种可能一定是有的。