今天给大家读的是2017年11月9日关于库存模块关于产品、重订购规则的一次提交。
改进结果：
修改产品类型时候如果该产品关联了重订购规则，不允许把产品类型修改为“服务”或“消耗品”。
改进原因：
先了解几个概念：
产品类型：“消耗品”，“服务”，“库存商品”。顾名思义，“消耗品”和“服务”都是不需要在系统里面进行库存管理。
重订货规则：也叫最小订货规则，设置了最小订货规则的产品会在系统运行MRP调度的时候，生成需求单。
现在我们来重现一下问题：
-
创建一个“维修服务”的产品，产品类型选择“库存商品”。
-
创建重订购规则。
-
发现产品类型选错了，再改为“服务”。
-
运行调度。
结果可以在需求单列表里面看到，系统已经自动生成了“维修服务”的需求单，但是因为“维修服务”并不需要管理库存，所以实际上这单据是我们不需要的。
代码说明：
@api.multi
def write(self, vals):
if 'uom_id' in vals:
new_uom = self.env['product.uom'].browse(vals['uom_id'])
updated = self.filtered(lambda template: template.uom_id != new_uom)
done_moves = self.env['stock.move'].search([('product_id', 'in', updated.mapped('product_variant_ids').ids)], limit=1)
if done_moves:
raise UserError(_("You can not change the unit of measure of a product that has already been used in a done stock move. If you need to change the unit of measure, you may deactivate this product."))
if 'type' in vals and vals['type'] != 'product' and sum(self.mapped('nbr_reordering_rules')) != 0:
raise UserError(_('You still have some active reordering rules on this product. Please archive or delete them first.'))
return super(ProductTemplate, self).write(vals)继承write方法，每次修改的时候都会执行，判断条件有三个:
-
修改了产品类型
'type' in vals -
产品类型修改为非“库存商品”
vals['type'] != 'product'。 -
该产品已经有重订购规则了
sum(self.mapped('nbr_reordering_rules')) != 0，nbr_reordering_rules是compute字段，值是该产品重订购规则的数量
mapped(func)：为self每个记录执行func，返回执行后的记录集或者列表。func可以是函数或是通过点操作符分隔的字段名字符（如’nbr_reordering_rules'）。
三个条件都符合则弹出提示说让用户先删掉关联的重订购规则。
其实也可以做到在跑运行调度的时候自动跳过这类情况。但是考虑到了不正确的设置还可能带来其他潜在风险，所以在修改的时候就提示。看不到🙈不代表不存在，把错误扼杀在摇篮之中 :-)。
原始提交信息
From a1ad6375efea21fd41cd15cb6749f409f17db123 Mon Sep 17 00:00:00 2001
From: Nicolas Martinelli <nim@odoo.com>
Date: Thu, 9 Nov 2017 13:00:47 +0100
Subject: [PATCH] [FIX] stock: reordering rules on service
1. Create a stockable product
2. Create a reordering rule
3. Ooops, change stockable into service
4. Run scheduler
Odoo created procurement for service products.
We prevent changing the product type if there are active reordering
rules. We could have silently skipped these products when running the
scheduler (in `_get_orderpoint_domain`), but that would have potentially
broke existing installations incorrectly set up.
opw-781128
---
addons/stock/models/product.py | 2 ++
1 file changed, 2 insertions(+)
diff --git a/addons/stock/models/product.py b/addons/stock/models/product.py
index d581fde285565..2a0e96f58ddba 100644
--- a/addons/stock/models/product.py
+++ b/addons/stock/models/product.py
@@ -505,6 +505,8 @@ def write(self, vals):
done_moves = self.env['stock.move'].search([('product_id', 'in', updated.mapped('product_variant_ids').ids)], limit=1)
if done_moves:
raise UserError(_("You can not change the unit of measure of a product that has already been used in a done stock move. If you need to change the unit of measure, you may deactivate this product."))
+ if 'type' in vals and vals['type'] != 'product' and sum(self.mapped('nbr_reordering_rules')) != 0:
+ raise UserError(_('You still have some active reordering rules on this product. Please archive or delete them first.'))
return super(ProductTemplate, self).write(vals)
@api.multi