好像有這樣一個(gè)理，不管你做什么，最好有點(diǎn)不一樣。跟一年前的自己比，跟目之所及的同行比，跟那些剛介入0O00但相當(dāng)資深的python程序員相比。能做出點(diǎn)標(biāo)準(zhǔn)但不同的東西出來，也算自己上進(jìn)的一個(gè)表現(xiàn)了。

?

一如既往的是，這個(gè)需求的實(shí)現(xiàn)過程并不如線下正在發(fā)生的業(yè)務(wù)那樣理所當(dāng)然。都知道可以基于薄利多銷設(shè)置階梯價(jià)格，原生的功能也支持基于SPU/SKU兩種不同的顆粒度進(jìn)行價(jià)格的維護(hù)?？雌饋?，原來基于單一銷售明細(xì)--sku+數(shù)量的取值邏輯，只要變更為基于按spu分組后的若干銷售明細(xì)--spu+數(shù)量的取值方式，就可以輕松完成任務(wù)了。

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

?

然而，當(dāng)你發(fā)現(xiàn)價(jià)格表里的所有方法，都只認(rèn)sku的時(shí)候，事情就變得麻煩一些了。為什么？我不感興趣，畢竟我不在乎多（少）一個(gè)合理的解釋。如果錯(cuò)（?）也有錯(cuò)的邏輯，我們就得理解一下這種邏輯是什么。

?

看起來，銷售價(jià)格表是基于銷售明細(xì)的業(yè)務(wù)邏輯設(shè)計(jì)的。如果對于銷售明細(xì)，sku才是真正有用的那個(gè)字段，你可以對銷售價(jià)格表抱有相同的期望。至于價(jià)格表里出現(xiàn)的spu？大概只是后期投訴多了，方便用戶維護(hù)罷了。

?

那問題來了，現(xiàn)在基于spu對銷售明細(xì)分組得到合計(jì)的數(shù)量，而價(jià)格表方法并不支持spu的輸入，該怎么改？講道理，我先來個(gè)標(biāo)準(zhǔn)寫法。

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(...)

?

你懂我意思吧？

?

不，你不想，至少我不太想。這種方式帶來的開發(fā)成本，測試成本我負(fù)擔(dān)不起，所以我打算換種寫法。

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)
})

?

以前我不喜歡這種面向結(jié)果湊出來的二開代碼，現(xiàn)在也無所謂了。我當(dāng)然更傾向于正統(tǒng)的那種二開方式，線上線下相一致帶來的好處會(huì)超出你的想象。但當(dāng)我把那些不同變體的銷售明細(xì)，當(dāng)成同一個(gè)變體的不同行來看的時(shí)候，好像別人也攔不住我，好像別人也不想攔我，那就這樣吧。