MRP算法比较

yypldwy2000

最初由 huaminge 发布
[B]各位好！请问楼主所讲的BOM展开是何意？是不是在每次MRP运算时再将该表一层一层的展开呀？如果是这样，真感到很不理解，我原先所设计的BOM是有很多的表组成，用于实现记录各相关数据，然后，用一个最明细的表在BOM审核的时候记录生产一个产成品最终需要每一个终部件的数量，这样在后面的MRP和很多其他相关运算中只需要从该明细表中直接取数即可。 [/B]

可以节省大量的时间。不过我认为在ERP系统中应该都是这样的。不可能计算一次变要展开一次。

wprusty

值得学习

WilliamGui

我先说说一般的MPS处理过程，再说说它的有足之处，
一般来说MPS的来源从MDS来，也可以说从主生产计划与销售订单来，根据时界按时段得到毛需求，考虑在库量、安全库存、在途量、批量得到预计库存等等，得到计划产出量，再根据提前期、安全时间、批量规则等得到计划投入，进而得到ATP等数据，完成计算。

WilliamNing

好容易又看到楼主。怎么话没说完就意趣阑珊啦

jinsonghuang

quote:
--------------------------------------------------------------------------------
最初由 huaminge 发布
各位好！请问楼主所讲的BOM展开是何意？是不是在每次MRP运算时再将该表一层一层的展开呀？如果是这样，真感到很不理解，我原先所设计的BOM是有很多的表组成，用于实现记录各相关数据，然后，用一个最明细的表在BOM审核的时候记录生产一个产成品最终需要每一个终部件的数量，这样在后面的MRP和很多其他相关运算中只需要从该明细表中直接取数即可。
--------------------------------------------------------------------------------


若设计变更导致的BOM经常变化呢?--这在企业中是常见的.按多表处理BOM,在全面计算一次的时间上,能快过传统算法吗?

freeman01

谁有厦门大学自动化系余锐林　 吴顺祥　的论文.

发到邮箱来,供学习.
http://www.wanfangdata.com.cn/qi ... 005/0506/050662.htm
freeman01@sina.com

samuel.wei

BOM展开的问题,我认为递归是最完善可靠的算法,其它的多多少少都存在问题或不够灵活,
并且我也不觉得哪里会慢.
TO :WilliamNing
   园整的问题很简单,单个需求(最低采购量、采购倍数、最小包装量)的时候就园整,多作的数量作为在库,计算下一个需求时冲减.
   如果你按某一个基数园整了,等结果出来了,换了供应商,结果园整的基数又不一样了,那是你们业务流程有问题.MRP是事前计算,不是事后计算,基础数据都变来变去,没法搞.管理上面也会晕头的.

samuel.wei

最初由 笨笨狗 发布
[B]如果涉及到互换件和通用件呢? [/B]

互换件的算法其实也不是很复杂,关键是业务部门的配合,比如MRP算出来了某个工单要使用代用料,可他们不按要求做,那么再好的MRP也是白费.
因为代用料的问题很有灵活性,所以要想用好相关的程序,必须在管理上比较死,严格按MRP算出来的结果进行.

我自已写的MRP就可以实现代用料,简单写一下以下几点要考虑
1.多代用品时的优先顺序
2.代用料的有效日和失效日
3.在库和PO的冲减方式
4.代用料尾数的处理(代用料剩1PCS,JOB 有10PCS的情况)

samuel.wei

最初由 samuel.wei 发布
[B]BOM展开的问题,我认为递归是最完善可靠的算法,其它的多多少少都存在问题或不够灵活,
并且我也不觉得哪里会慢.
TO :WilliamNing
   园整的问题很简单,单个需求(最低采购量、采购倍数、最小包装量)的时候就园整,多作的数量作为在库,计算下一个需求时冲减.
   如果你按某一个基数园整了,等结果出来了,换了供应商,结果园整的基数又不一样了,那是你们业务流程有问题.MRP是事前计算,不是事后计算,基础数据都变来变去,没法搞.管理上面也会晕头的. [/B]

说明一下,是在SERVER端写的PL/SQL ,不然慢死.

gino_1982

深奥的问题！