ERP顾问最热爱的网络——金蝶社区 - 关于MRP计算的几个问题交流

会员名称:

登录密码:

(找回密码)

保存登录

会员注册

分类

管理

· 生产与运营 (399)
· 供应链 (1449)
· 财务 (1301)
· 人力资源 (316)
· 小企业管理 (19972)
· 集团管控 (455)
· 战略 (58)
· 其它 (815)

技术

· SOA (2030)
· EAS BOS (278)
· K/3 BOS (2595)
· Apusic (5)
· 网络技术 (229)
· 数据库 (336)

应用

· 金蝶EAS (463)
· 金蝶K/3 (32770)
· 金蝶配套 (157)
· 金蝶KIS (22520)
· IT规划 (119)
· ERP咨询与实施 (502)
· ERP行业分析 (1707)
· 其它 (777)

个人知识管理

· 职业发展 (64)
· 商务沟通 (48)
· 实用知识 (136)
· 人生感悟 (62)
· 社区事务 (560)

问题

上个主题下个主题

主题：关于MRP计算的几个问题交流

Danny Luan

IT 行业

Ta擅长：

本周回答(0),本月回答(0)

发贴时间：2008-3-27 16:58:46 完成时间： 2008-5-1 17:30:16

赠分：10 回答：15 已经到期

第一个问题（已经解决）

问题：建立物料A、B、C； B和C为A的下层物料，在没有预计量的情况下，MRP计算后只产生A的计划订单，未产生B、C的计划订单，检查基础资料、BOM都没有问题。

经过反复查找，发现只要进行一次低位码的维护就OK了，这个问题折腾了我好长时间。

待续

Dream and you will be there.
科技以人为本，软件以应用为本

意见评论 (12)

苏一笑

制造业版主

MRP计算过程中，第一个作业过程即是检查，其中包括低位码维护、BOM检查等。养成检查的习惯，会减少出错的可能。
苏一笑

意见时间：2008-4-2 8:45:12
Danny Luan

其实我们的低位码维护速度非常快，几秒钟就搞定了，在这种情况下，我认为K/3完全应该把它作为MRP计算的一部分，因为本来低位码维护就是MRP的一部分算法而已，作为应用人员，没有必要老想着这么回事情，我正在做V11的测试，不知道是否改过这一部分。
Dream and you will be there.
科技以人为本，软件以应用为本

意见时间：2008-4-2 9:02:16
苏一笑

制造业版主

针对贵公司确实如此。
但K3系统作为通用性软件，必须兼顾不同企业的实际作业要求。如果客户的物料代码达3万个以上，BOM在三层以上，就不是数秒能够解决的。所以在系统中体现为可选择的功能，是优化作业的必然选择。
苏一笑

意见时间：2008-4-7 12:12:51
Danny Luan

不完全同意你的看法。

至少应该做一个选项，默认是计算MRP时自动计算低位码，对于有计算瓶颈的公司，可以自己修改该选项。

另外，若确实数据量很大的话，计算MRP也是需要很长时间的，计算低位码所占的时间比重仍然可以忽略不计。

看来目前K/3的性能确实还可以，到目前为止没有遇到大的性能问题，可能与我们数据量不大，并发用户不多有关系。
Dream and you will be there.
科技以人为本，软件以应用为本

意见时间：2008-4-7 12:51:25
阿条

咿呀，多谢了，我正在郁闷呢，怎么我的MRP就运算不了呢，NND
原来是这个问题，支持你

意见时间：2008-4-18 11:19:47
honest

其实在V10.1之前版本在MRP的方案参数中提供选项，MRP计算前自动进行低位码维护；V10.2以后MRP采用向导式计算，其中有预检查步骤，提示要进行低位码维护；但无论是哪个版本的客户都会反馈类似问题，其实个人认为关键是MRP实施时，没有制定MRP运行相关的指导手册。
海纳百川

意见时间：2008-5-4 20:10:29
cat331

我们公司的物料需求计划倒是希望能够只先进行第一层的运算，待确认第一层运算正确后（有时第一层出来的生产计划单需要调整数量），再进行第二层的运算，希望能够这样分成进行！每次都能够管控到位

意见时间：2008-5-21 18:25:00
风无雨

金蝶K/3版主

有改动过BOM的，都需要进行低位码维护。
不在能知，乃在能行。

意见时间：2008-5-22 12:45:53
游客

我这边对于某个仅用于BOM的物料，通过SQL将虚拟件修改为自制件，并且设置了MRP计算时候直接生成采购申请，计算MRP时发现结果出来了该物料的下层物料，最后发现是由于新版本具有跳层功能的原因，在虚拟件的BOM中，系统默认的是跳层的，修改物料的属性后，BOM中仍然是跳层的。
个人分析跳层的一个非常好的用处是可以对已经使用的自制件，后来想作为虚拟件来管理，系统不允许修改物料属性，可以通过跳层来实现。

意见时间：2008-5-29 8:45:35
Danny Luan

我这边对于某个仅用于BOM的物料，通过SQL将虚拟件修改为自制件，并且设置了MRP计算时候直接生成采购申请，计算MRP时发现结果出来了该物料的下层物料，最后发现是由于新版本具有跳层功能的原因，在虚拟件的BOM中，系统默认的是跳层的，修改物料的属性后，BOM中仍然是跳层的。把这个跳层改为否，就正确了。
个人分析跳层的一个非常好的用处是可以对已经使用的自制件，后来想作为虚拟件来管理，系统不允许修改物料属性，可以通过跳层来实现。
修改时间：2008-5-29 8:48:49
Dream and you will be there.
科技以人为本，软件以应用为本

意见时间：2008-5-29 8:46:52
Danny Luan

继续：后台直接修改物料的属性，（仅仅做了BOM，没有其他单据），从虚拟件更改为自制件，当时没有考虑到成本对象的问题，刚测试过了，只要修改了以后，把该物料在编辑界面中调出来，保存一下，系统就会帮着再产生一个成本对象了。
Dream and you will be there.
科技以人为本，软件以应用为本

意见时间：2008-6-4 14:14:58
由零开始

感谢分享！
关注企业信息化，个人知识管理
http://blog.vsharing.com/sjzljl/

意见时间：2008-9-8 13:53:46

好望角

IT 行业

Ta擅长：

金蝶K/3(88),金蝶KIS(30) 本周回答(0),本月回答(0)

回答时间：2008-3-27 17:41:48

多谢你的经验分享.低位码维护这个工作的确至关重要,我以前也有类似经历.

稳健发展，追求卓越。

发文者评价：	（共获积分：10）
	根据投票自动设置的最佳答案
网友评价：	75% 25% (目前有 11 人评价)
你的评价：

意见评论 (1)

其他回答

Danny Luan

IT 行业

Ta擅长：

本周回答(0),本月回答(0)

回答时间：2008-4-2 11:04:42

问题2

关于MRP的计算来源问题，我们公司计划产品量是确定的，所以我们不使用MPS功能。
MRP的来源包括销售订单和销售预测，我们不希望销售订单对计算产生影响，所以我们在MRP选项中选择产品预测。

我们现在实际的做法是连产品预测也不做，直接下产成品的生产任务单，MRP计算的时候会以此展开产生计划订单。

这样做的好处是：不需要考虑不同状态的预测单对计算的影响，产成品的生产任务单就是直接的需求来源，计划变动时，可以直接修改该生产任务单。到目前为止，运行正常。

关于缺点，我能想到的主要是关于合并方面的，在一张预测单上的需求，系统有选项可以进行合并，但考虑到它的合并与我们实际想要的合并仍然有差距，也就放弃了。

Dream and you will be there.
科技以人为本，软件以应用为本

意见评论 (1)

Danny Luan

IT 行业

Ta擅长：

本周回答(0),本月回答(0)

回答时间：2008-4-2 11:09:59

问题3

我们现在是选择指定物料计算MRP，就是指定某一个产成品，我的理解是系统会根据这个产成品（我选择的是多级向下展开）的BOM找到有哪些物料需要参与计算。

根据用户手册的意思，这个物料选择应该是指需求，但实际看下来，它也会确定系统中有哪些下层物料需要参与计算，这些物料参与计算时，也会考虑其他产成品产生的预计量等，换句话说，选择物料只是选择所有5000多条物料中哪些物料（比如500条）参与MRP运算，对于这500条物料来说，计算的结果与不选择物料是一样的。（前提是我们没有销售订单和产品预测，只有产成品的预测单）

Dream and you will be there.
科技以人为本，软件以应用为本

意见评论 (2)

分类

QnA互动问答 » 管理 » 生产与运营