OpenERP的MRP运算的核心对象--Procurement Order
-
需求的来源和转化
==========
我们在上回介绍了需求单运行时如何因为产品的Supply Method(供应方式）的不同而转化为不同的业务单据（生产单，采购单）以满足Proc所代表的需求，以及如何自动定时来运算需求。如果我们还做了上回介绍中提到的一个试验，那么还会进一步了解到如果产品类型为Service(服务），Supply Mechod(供应方式）为生产的产品所对应的Proc会转化为任务单。这个理解起来也是顺理成章：任务单用以满足对服务的需求。产品类型中还有一个被称为Consumable的，这类产品实际上不会产生需求转化，不参与需求运算。可以简单理解为这种产品有无限库存，随需随取，无需生成采购/生产等单据来满足需求，一般用以定义那些低值易耗的原料，比如生产中需要的螺丝，我们会定期采购大量的螺丝而无需根据生产需求来计算其用量。其实说到这里我们就感受到了需求的来源这个话题，也能基本回答上一回中为什么对以Supply Method为生产的产品运行其相关Proc会在生成生产单的同时又生成了大量与此生产单相关的Proc. 这是因为生产过程会产生对原料的需求，也就是说生产就是一个需求的来源。可是，我们在上回的最后问的是："需求的最终来源是什么？生产是一个需求的来源，可是生产的目的最终还是用来满足客户的需求。所以，客户的需求是需求的最终来源，在OpenERP里就是销售订单。销售订单的确认即会生成需求单Proc.
再来看看需求类型的问题。其实对于类型的划分按照不同的标准划分就有不同的答案。我这里所想要涉及的Proc的类型划分是在产品定义和Proc定义上都出现的一个字段：Procurement Method. 这里有两个可选项：Make To Order（MTO) 和 Make To Stock（MTS)。我们一般将之翻译为"面向订单的生产"/"面向库存的生产"，其实这个翻译不够准确，Make在这里不仅是生产的意思。我们也看到了在前几回的Proc介绍中MTO类型的Proc会转化为采购单而与生产无关。我个人将OpenERP中的MTO理解为"直接需求"，MTS理解为"间接需求"或"面向库存的需求" 或 "计划性需求"。那么她们之间到底有什么不同呢？
这里是关键点：[b]MTO能通过运行处理直接生成其他的业务单据（比如：采购单，生产单，任务单）[/b]，这在之前的操作中已经了解。[b]而MTS则比较特殊，他本身不会生成其他业务单据，但是它的存在可能会导致其他的MTO类型的Proc的产生[/b]. 我们这就通过创建一个销售订单来证实：销售订单是否会生成需求单，MTS类型的需求单是否"有可能"导致其它MTO类型的需求单的生成：
用以下内容创建一张销售订单：
客户: China Export
订单行：
订单行1- 产品：PC1 数量：10, Procurement Method: [b]MTO[/b]
订单行2- 产品：Keyboard 数量：30, Procurement Method：[b]MTS[/b]
[b]注：Procurement Method 在订单行窗口的Extra Info页中，其默认值来自于产品表单上的Procurement Method的设定，这里注意将PC1从默认的MTS改为MTO[/b]
[attachimg=1]
[attachimg=2]
好了我们的客户同时订了两个不同的产品，我们也为其定义了不同的需求类型，记住订单号：SO014， 然后确认订单。然后到Procurement Exception菜单项这里，点击Clear以清除默认的过滤条件，然后在Source Document中输入SO014,查询与SO014订单相关的Proc:
[attachimg=3]
的确，当订单确认后两个订单行分别生成了相应的Proc,其上的产品，数量，Procurement Method都与订单行一致。如果我们运行这些Proc会怎么样呢？on order(MTO）类型的Proc我们已经做过试验，不出意外的话，会生成一张生产单，和一些生产所需原料的需求单。而from stock(MTS）类型的Proc还不知道会如何反应。点击"Compute Scheduler"，在弹出窗口中再点击"Compute Schedulers"。然后返回Procurement Exception菜单项，仍然查询SO014相关的Proc:
[attachimg=4]
会发现的确如前预料，PC1相关的MTO类型的Proc运行后生成了生产单MO/00011,而该生产单又生成了大量的以SO0014:MO/0011为源单据的需求单（绿色框所示）。可是，但是，可但是，我们from stock的Proc却坚决的毫不犹豫的又给了我们一个Exception. 其错误原因倒也写得详细："库存不足，未定义最小库存规则" 。从这个错误似乎能推出OpenERP对 这个MTS类型的Proc的处理过程：面向库存的需求，当然首先检查库存是否能满足本需求的要求，当库存不足时产生Exception,同时其又似乎尝试做库存补货的操作以使库存量能满足Proc,但是这里又碰到了没有设置补货规则（最小库存规则）的问题。
如果大家还记得第二回中的内容，我们提到过"最小库存规则"这个说法。这里要提醒一点：我们这里讨论的Proc话题基于的是目前最新的OpenERP V6.1 发行版本，V6.0x及以下的版本最小库存的设定在Warehouse-Configuration-Automatic Procurement-Minimum Stock Rule, 而不会如6.1这样在产品定义界面中出现。我们这就为Keyboard设置最小库存规则：
[attachimg=5]
这里的我们对仓库为：Your Company, Stock Location(存货地点）为：Stock设置了最小订货规则。这里的Minimun Quantity和Maximun Quantity的意思是：当库存数量不足10个时，该规则要求补货至最大库存量，即100个。所以Minimun Quantity是前提条件，而最大库存量是计算实际补货需求量的基础。由此我们可以推测出：库存规则的设定，就会衍化出物料需求。根据我们之前强调的“哪里有物料需求哪里就有需求单”的口诀，当这个库存规则条件满足（Minimum Quantity），就会产生物料需求，从而会产生需求单。再来"Compute Schedulers"，然后再来搜索SO0014相关的Proc。
发现那个from stock(MTS）类型的Proc仍然是Exception状态，但是仅仅是库存不足的错误提示，而没有了之前未设置库存规则的抱怨了。可是在列表中没有发现有新生成的需求单。其实，新的需求单已经悄然生成，只是不再与SO014这个销售订单有任何直接关系，所以你无法通过源单据为SO014来过滤该Proc. 我们换为查找产品为"Keyboard"的所有Proc:
[attachimg=6]
你会发现一个源单据为OP/00013 的Proc而其需求类型为MTO。这证实了我们之前所说："MTS类型的需求单本身不会生成其他业务单据，但是它的存在可能会导致其他的MTO类型的Proc的产生." 再来注意一下源单据号，这里的OP代表Order Point, 看来这个需求单的确是因为激发了库存规则（即Order Point）而产生的。至此，我们了解了产品设置界面上：Product Type, Procurement Method，Supply Method, Minmun Stock Rule 之间的关系和对Proc的影响，以及需求的终极来源为销售订单，销售订单的确认导致需求的确认，每个订单行会生成对应的Proc 。
我们接下来还需要了解需求产生的数量，地点，时间，它们在Proc上的反映，以及OpenERP对它们的处理。而要讲清楚这些问题，我们首先必须理解OpenERP的一个独特设计：复式库存计算， 敬请期待。 -
库存规则和管理计划
===========
本回是对前几回介绍内容的一个回顾，同时简单的探讨一下库存管理中涉及的一些方法。
根据产品的供应方式（Supply Method）不同(Buy or Produce) ，我们可以通过外购，或者自产来满足需求；同时根据产品的类型不同，需求可以通过采购单（Supply Method + Product Type：Buy + Stockable Product/Service), 生产单（Produce + Stockable Product), 任务单（Produce + Service)来满足。物料需求有两种类型：MTO和MTS。 MTO类型的需求将不考虑库存情况，即时根据上诉规则转化为对应的业务单据以平衡需求。MTS类型的需求则会检查现有库存，尽可能通过消耗库存来平衡需求，同时由于库存规则的存在，当库存量低于最小库存时会激发补货需求，该需求为MTO类型，因此可转化为采购单，生产单，任务单等。我们也了解到销售订单是需求的终极来源，销售订单的每一个订单行都可以生成一个对应的需求单，订单行在创建时可以指定需求类型（MTO或MTS），生成的对应的需求单也拥有同样的需求类型。需求在OpenERP中有状态的变化和工作流的定义，他们与销售，生产，采购有紧密的关系，而其在地点，时间，数量三个维度上与OpenERP中的Stock Move对象密不可分。这将在"OpenERP的复式库存设计"介绍结束后进一步讲解。
我们经常会听说某某ERP帮助您真正实现"零库存"这样的忽悠说辞。的确，从某种意义上"库存永远是坏的"（Inventory is always bad ），因为她会导致资金的占用。但是，库存成本与收益之间是一对矛盾，一方面企业总是尽可能的控制库存成本，很多企业库存水平每降低一天，整体现金流的水平就会有显著提高。另一方面，库存与企业运行效率和客户服务水平有着密切的关系。保持一定数量的库存往往是必须的，这主要由于以下的约束条件：
＃供货时间，从供应商处获取物料需要时间，为了不影响正常的销售与生产，必须保持物料储备。
＃不确定性，需求并不能完全准确预测，只有保证一定的库存储备才能应对突发的需求增量。
＃规模经济，在生产，运输，仓促的流程中，物料的规模对单位成本控制很重要。
所以，MTO和MTS的需求方式在企业中往往会同时交替存在。比如某些生产企业会以MTS的方式面向库存生产一些关键部件（有的时候我们称之为：BTS(Build TO Stock） ） ，而在产品交付前采用ATO(Assembly To Order －按单装配）的MTO需求模式。而面向库存的需求（MTS）往往占大多数，因此合理的库存规则的设定对库存管理水平有很大的影响。这里要了解的是，OpenERP中所涉及的最大、最小库存规则是众多库存管理方法中的一种。
OpenERP中对库存的最小，最大需量的设计看似很简单，其实这也是一个极简化的库存管理模型，因为它并没有告诉你如何来设置这些数值。如何确定最小库存的触发点是最合适的呢？最大和最小库存的差值应该设多少呢？如果差值较小，采购周期就短，反之则长，什么样的采购周期是最合适的呢？
理论上对此有不少的研究，其中就有著名的经济订货批量模型（EOQ)， EOQ是通过对存货持有成本和订货成本的考查，确定成本最低的补给订货批量：
[attachimg=1]
计算公式为：
[attachimg=2]
其中，Q * 为经济订货批量；C为单次订货成本；R为年总需求量；H为单位产品的库存成本
但是，这种模型忽略很多对成本的影响因素，比如：单位运输成本的变动，当订单批量越大，单位运输费率就会下降；订货次数的多少对运输经济性的影响；订货的数量折扣，不同数量的订货其采购成本可能不同。因此，其计算结果往往只能作为一个参考。
另外，在库存管理中我们可以采用经典的ABC库存分类法。ABC分析法采用了帕雷托规则（Pareto principle)， 指出一般企业的物料中如果采用物料价值来衡量其重要程度，大约20%的原料占据80%的总成本，剩下80%的物料只占20%的总成本。据此，将物料分类为ABC三种类型。
＃A类型： 5%的物料，占70%的成本
＃B类型： 10%的物料，占15%的成本
＃C类型： 85%的物料，占15%的成本
[attachimg=3]
对于A和B类物料，Min和Max相对对应该比较低，补货频率应该较高，以此来控制整体库存。而对C物料，Max则可以相对提高，减少运输成本。
下一回按计划讲解 "OpenERP的复式库存”，是不是用视频会好一点？ -
[quote author=xuxudodo link=topic=2923.msg11370#msg11370 date=1339730451]
发现一个笔误:
[quote]
需求的来源和转化
==========
.....
再来看看需求类型的问题。其实对于类型的划分按照不同的标准划分就有不同的答案。我这里所想要涉及的Proc的类型划分是在产品定义和Proc定义上都出现的一个字段：Procurement Method. 这里有两个可选项：Make To Order（MTS) 和 Make To Stock（MTO)。
[/quote]
应该是:
Make To Order（MTO) 和 Make To Stock（MTS)。
[/quote]
已修改，非常感谢 -
[quote author=ccdos link=topic=2923.msg12359#msg12359 date=1353517247]
MTS 的需求 首先是导致可用库存数的 减少，从而触发 最小库存规则触发 补货的
[/quote]
感谢捧场，你的理解是正确的 -
大致可以用老肖的一段话来总结下：
1） 销售出某MTO的产品A
2） 销售单(SO:Sale Order)确认时候，系统自动生成产品A的补货单(PO:Procurement Order)
3） 该PO导致系统生成产品A的制造单(MO:Manufacturing Order)
4） 随着该MO的执行，系统会根据BOM计算产品零部件的补货单
5） 零部件补货单会导致系统生成库间移动单（INT：Internal Moves，相当于领料单）
6） 如果零部件是MTO的产品，该INT 又会触发新的PO及MO，如果该零部件是MTS的，且库存
不足领料数量，则系统将处于待料状态（Waiting）
7） 待料状态下，等待一天后，最小库存规则会自动引发该零部件的补货单，该补货单又会产生采购
单（PO：Purchase Order）
8） 采购员确认系统生成的采购单，且采购零部件入库后，待料状态结束，生产可以继续进行。
自己在看源码时，对以上过程中一些库存移动相关的库位之间的转移有些疑惑，期待校长允诺的"OpenERP的复式库存"大作,希望能对以上过程中的库存移动以及相关库位之间转移多做些解释，半年多了哦 ;D -
OpenERP复式库存介绍参见： [检测到链接无效，已移除]
-
看不到他强大在那里.
还没有用到BOM的资料,是不是太简单了些? -
点击这个的时候出错了，什么原因啊？
OpenERP Server Error
Client Traceback (most recent call last):
File "/usr/lib/pymodules/python2.7/openerp/addons/web/http.py", line 204, in dispatch
response["result"] = method(self, **self.params)
File "/usr/lib/pymodules/python2.7/openerp/addons/web/controllers/main.py", line 1132, in call_button
action = self._call_kw(req, model, method, args, {})
File "/usr/lib/pymodules/python2.7/openerp/addons/web/controllers/main.py", line 1120, in _call_kw
return getattr(req.session.model(model), method)(*args, **kwargs)
File "/usr/lib/pymodules/python2.7/openerp/addons/web/session.py", line 42, in proxy
result = self.proxy.execute_kw(self.session._db, self.session._uid, self.session._password, self.model, method, args, kw)
File "/usr/lib/pymodules/python2.7/openerp/addons/web/session.py", line 30, in proxy_method
result = self.session.send(self.service_name, method, *args)
File "/usr/lib/pymodules/python2.7/openerp/addons/web/session.py", line 103, in send
raise xmlrpclib.Fault(openerp.tools.ustr(e), formatted_info) -
看了8.0后怎么感觉完全不一样了。。。找不到supply method，取代的是Supply Chain Information？
product里不选router就表示是MTS？
但是需求单里又有2个地方Preferred Routes和rule。这个rule就是supply rule？真有点搞晕了。。。。
[quote author=digitalsatori link=topic=2923.msg11246#msg11246 date=1338769425]
需求的来源和转化
==========
我们在上回介绍了需求单运行时如何因为产品的Supply Method(供应方式）的不同而转化为不同的业务单据（生产单，采购单）以满足Proc所代表的需求，以及如何自动定时来运算需求。如果我们还做了上回介绍中提到的一个试验，那么还会进一步了解到如果产品类型为Service(服务），Supply Mechod(供应方式）为生产的产品所对应的Proc会转化为任务单。这个理解起来也是顺理成章：任务单用以满足对服务的需求。产品类型中还有一个被称为Consumable的，这类产品实际上不会产生需求转化，不参与需求运算。可以简单理解为这种产品有无限库存，随需随取，无需生成采购/生产等单据来满足需求，一般用以定义那些低值易耗的原料，比如生产中需要的螺丝，我们会定期采购大量的螺丝而无需根据生产需求来计算其用量。其实说到这里我们就感受到了需求的来源这个话题，也能基本回答上一回中为什么对以Supply Method为生产的产品运行其相关Proc会在生成生产单的同时又生成了大量与此生产单相关的Proc. 这是因为生产过程会产生对原料的需求，也就是说生产就是一个需求的来源。可是，我们在上回的最后问的是："需求的最终来源是什么？生产是一个需求的来源，可是生产的目的最终还是用来满足客户的需求。所以，客户的需求是需求的最终来源，在OpenERP里就是销售订单。销售订单的确认即会生成需求单Proc.
再来看看需求类型的问题。其实对于类型的划分按照不同的标准划分就有不同的答案。我这里所想要涉及的Proc的类型划分是在产品定义和Proc定义上都出现的一个字段：Procurement Method. 这里有两个可选项：Make To Order（MTO) 和 Make To Stock（MTS)。我们一般将之翻译为"面向订单的生产"/"面向库存的生产"，其实这个翻译不够准确，Make在这里不仅是生产的意思。我们也看到了在前几回的Proc介绍中MTO类型的Proc会转化为采购单而与生产无关。我个人将OpenERP中的MTO理解为"直接需求"，MTS理解为"间接需求"或"面向库存的需求" 或 "计划性需求"。那么她们之间到底有什么不同呢？
这里是关键点：[b]MTO能通过运行处理直接生成其他的业务单据（比如：采购单，生产单，任务单）[/b]，这在之前的操作中已经了解。[b]而MTS则比较特殊，他本身不会生成其他业务单据，但是它的存在可能会导致其他的MTO类型的Proc的产生[/b]. 我们这就通过创建一个销售订单来证实：销售订单是否会生成需求单，MTS类型的需求单是否"有可能"导致其它MTO类型的需求单的生成：
用以下内容创建一张销售订单：
客户: China Export
订单行：
订单行1- 产品：PC1 数量：10, Procurement Method: [b]MTO[/b]
订单行2- 产品：Keyboard 数量：30, Procurement Method：[b]MTS[/b]
[b]注：Procurement Method 在订单行窗口的Extra Info页中，其默认值来自于产品表单上的Procurement Method的设定，这里注意将PC1从默认的MTS改为MTO[/b]
[attachimg=1]
[attachimg=2]
好了我们的客户同时订了两个不同的产品，我们也为其定义了不同的需求类型，记住订单号：SO014， 然后确认订单。然后到Procurement Exception菜单项这里，点击Clear以清除默认的过滤条件，然后在Source Document中输入SO014,查询与SO014订单相关的Proc:
[attachimg=3]
的确，当订单确认后两个订单行分别生成了相应的Proc,其上的产品，数量，Procurement Method都与订单行一致。如果我们运行这些Proc会怎么样呢？on order(MTO）类型的Proc我们已经做过试验，不出意外的话，会生成一张生产单，和一些生产所需原料的需求单。而from stock(MTS）类型的Proc还不知道会如何反应。点击"Compute Scheduler"，在弹出窗口中再点击"Compute Schedulers"。然后返回Procurement Exception菜单项，仍然查询SO014相关的Proc:
[attachimg=4]
会发现的确如前预料，PC1相关的MTO类型的Proc运行后生成了生产单MO/00011,而该生产单又生成了大量的以SO0014:MO/0011为源单据的需求单（绿色框所示）。可是，但是，可但是，我们from stock的Proc却坚决的毫不犹豫的又给了我们一个Exception. 其错误原因倒也写得详细："库存不足，未定义最小库存规则" 。从这个错误似乎能推出OpenERP对 这个MTS类型的Proc的处理过程：面向库存的需求，当然首先检查库存是否能满足本需求的要求，当库存不足时产生Exception,同时其又似乎尝试做库存补货的操作以使库存量能满足Proc,但是这里又碰到了没有设置补货规则（最小库存规则）的问题。
如果大家还记得第二回中的内容，我们提到过"最小库存规则"这个说法。这里要提醒一点：我们这里讨论的Proc话题基于的是目前最新的OpenERP V6.1 发行版本，V6.0x及以下的版本最小库存的设定在Warehouse-Configuration-Automatic Procurement-Minimum Stock Rule, 而不会如6.1这样在产品定义界面中出现。我们这就为Keyboard设置最小库存规则：
[attachimg=5]
这里的我们对仓库为：Your Company, Stock Location(存货地点）为：Stock设置了最小订货规则。这里的Minimun Quantity和Maximun Quantity的意思是：当库存数量不足10个时，该规则要求补货至最大库存量，即100个。所以Minimun Quantity是前提条件，而最大库存量是计算实际补货需求量的基础。由此我们可以推测出：库存规则的设定，就会衍化出物料需求。根据我们之前强调的“哪里有物料需求哪里就有需求单”的口诀，当这个库存规则条件满足（Minimum Quantity），就会产生物料需求，从而会产生需求单。再来"Compute Schedulers"，然后再来搜索SO0014相关的Proc。
发现那个from stock(MTS）类型的Proc仍然是Exception状态，但是仅仅是库存不足的错误提示，而没有了之前未设置库存规则的抱怨了。可是在列表中没有发现有新生成的需求单。其实，新的需求单已经悄然生成，只是不再与SO014这个销售订单有任何直接关系，所以你无法通过源单据为SO014来过滤该Proc. 我们换为查找产品为"Keyboard"的所有Proc:
[attachimg=6]
你会发现一个源单据为OP/00013 的Proc而其需求类型为MTO。这证实了我们之前所说："MTS类型的需求单本身不会生成其他业务单据，但是它的存在可能会导致其他的MTO类型的Proc的产生." 再来注意一下源单据号，这里的OP代表Order Point, 看来这个需求单的确是因为激发了库存规则（即Order Point）而产生的。至此，我们了解了产品设置界面上：Product Type, Procurement Method，Supply Method, Minmun Stock Rule 之间的关系和对Proc的影响，以及需求的终极来源为销售订单，销售订单的确认导致需求的确认，每个订单行会生成对应的Proc 。
我们接下来还需要了解需求产生的数量，地点，时间，它们在Proc上的反映，以及OpenERP对它们的处理。而要讲清楚这些问题，我们首先必须理解OpenERP的一个独特设计：复式库存计算， 敬请期待。
[/quote]
值得一看,看完后继续实践.
::) ::) ::)真棒