0O00-按产品模板获取销售价格

好像有这样一个理，不管你做什么，最好有点不一样。跟一年前的自己比，跟目之所及的同行比，跟那些刚介入0O00但相当资深的python程序员相比。能做出点标准但不同的东西出来，也算自己上进的一个表现了。

一如既往的是，这个需求的实现过程并不如线下正在发生的业务那样理所当然。都知道可以基于薄利多销设置阶梯价格，原生的功能也支持基于SPU/SKU两种不同的颗粒度进行价格的维护。看起来，原来基于单一销售明细--sku+数量的取值逻辑，只要变更为基于按spu分组后的若干销售明细--spu+数量的取值方式，就可以轻松完成任务了。

def _get_product_price(self, product, quantity, uom=None, date=False, **kwargs):

然而，当你发现价格表里的所有方法，都只认sku的时候，事情就变得麻烦一些了。为什么？我不感兴趣，毕竟我不在乎多（少）一个合理的解释。如果错（?）也有错的逻辑，我们就得理解一下这种逻辑是什么。

看起来，销售价格表是基于销售明细的业务逻辑设计的。如果对于销售明细，sku才是真正有用的那个字段，你可以对销售价格表抱有相同的期望。至于价格表里出现的spu？大概只是后期投诉多了，方便用户维护罢了。

那问题来了，现在基于spu对销售明细分组得到合计的数量，而价格表方法并不支持spu的输入，该怎么改？讲道理，我先来个标准写法。

def _get_product_price(self, product, quantity, uom=None, date=False, **kwargs):
   product_tmpl = kwargs.get('product_tmpl')
   if not product_tmpl:
       return super()._get_product_price(...)

你懂我意思吧？

不，你不想，至少我不太想。这种方式带来的开发成本，测试成本我负担不起，所以我打算换种写法。

first_sku, total_qty = this_order_lines[0].product_id, sum(this_order_lines.mapped('product_uom_qty'))

this_order_lines.write({
   'price_unit': self.pricelist_id._get_product_price(first_sku, total_qty)
})

以前我不喜欢这种面向结果凑出来的二开代码，现在也无所谓了。我当然更倾向于正统的那种二开方式，线上线下相一致带来的好处会超出你的想象。但当我把那些不同变体的销售明细，当成同一个变体的不同行来看的时候，好像别人也拦不住我，好像别人也不想拦我，那就这样吧。