Rss & SiteMap

E树ERP论坛(ERP爱好者之家) http://www.kntsoft.cn/bbs

E树免费ERP系统(2个在线用户学习版,无其它任何限制)
共1 条记录, 每页显示 100 条, 页签: [1]
[浏览完整版]

标题:发布视频教程: MRP运算时自动挪料

1楼
E树软件 发表于:2021/3/31 23:36:47
*****
MRP运算时自动挪料
*****

1>.MRP挪料是MRP计算过程中的虚假挪料,和"生产-->生产单挪料(真实挪料)"是不同的!
2>.MRP挪料的目的: 是为了在"MRP供应关联查询(正向查询) ",能根据销售订单的交期先后,
         评估目前"库存+工单在线"可以支撑到哪个销售订单

*** 下面,我们来演示MRP挪料的效果 ***

3>.以一款最简单的产品AAA1,下级只有一个子料AAA2,先下三个不同交期的销售订单(每单数量100)
4>.跑MRP,显示缺料300个.(这个很简单,大家口算都能算出来)
5>.在"查询生产单"界面,批量审核MRP产生的三个工单(此界面左侧条件中,可以指定或更正生产仓库)
   (为了直观, 我们把三个工单号改ID为"工单001/002/003")
6>.库存调加100个AAA2, 并将其中80个,发料给"工单002"(库存还剩余20个)
7>.我们再下采购订单100个AAA2. 
8>.然后,我们跑MRP,并在"MRP供应关联查询(正向查询) "查看三个订单的缺料情况,我们发现:
   订单1分配了20个剩余库存, 另外80个是由采购在途提供.
   现在问题就来了,由于AAA2是共用件,虽然你发料是发给"工单002",那PMC计算订单缺料时,
   希望这笔工单在线量,可以吐出来,分配给"工单001",以便PMC能按订单的交期先后顺序,
   评估目前"库存+工单在线"可以支撑到哪个销售订单.
  (但目前查出是:订单001就缺料,要由在途PO供料,不符合要求!)

*** 为了解决这个问题,我们引入了MRP自动挪料功能 ***

1>.物料数据维护中,有一个MRP参数: MRP运算时允许挪料
2>.MRP运算模块中,还有一个总开关: MRP自动挪料, 它有三个选择
   A>.禁止MRP自动工单挪料
   B>.优先工单挪料,然后再按时间进行MRP计算  (此次演示采用这个参数)
   C>.按时间进行MRP计算,缺料时再自动MRP挪料

*** 设置好MRP自动挪料参数后,我们来看看效果 ***

1>.我们设置好AAA2的参数,并且MRP运算中,选择: 优先工单挪料,然后再按时间进行MRP计算
   然后跑MRP, 查到"订单001"中,不再需要在途采购了.(即: 不缺料了)
2>.然后,我们在MRP运算过程数据查询中,查AAA2的明细,也看到它的解释中,说明了:
   工单002的物料,挪给工单001了. (挪入挪出双方,都有明细记录)
3>.然后,我们在"MRP供应关联查询(正向查询) "查"订单002",它由于挪出了80个原料,
   因此,它需要在途采购来支撑其中100个数量.(缺料啦!!!)

***这样,就达到我们目的:评估目前"库存+工单在线"只能支持到"订单001"***
?
4>.下面,我们讲一下第3个MRP挪料类型: 按时间进行MRP计算,缺料时再自动MRP挪料,
   为了看到效果,我们把"工单002"的退料,再发80个到"工单003"上.再跑MRP. 我们看到:
   工单001是由"剩余库存20 + 在途采购80"来支撑,(因为按时间顺序,是先采购到货),
   工单002是由"在途采购20 + 挪料过来80"来支撑,(模拟库存用完了,才开始挪后面的工单),
   工单003是由"采购申请单100个"来支撑.(缺料了,没办法,只了申请购买了)
   
因此,我们明白了二者的区别:
 
B>.优先工单挪料,然后再按时间进行MRP计算   :不管有没有库存,先挪用后面工单
C>.按时间进行MRP计算,缺料时再自动MRP挪料 :只有当模拟到这个时点库存不够时,才挪用后面工单

Bilibili: https://www.bilibili.com/video/BV1Fv411h7EN/
腾讯视频: https://v.qq.com/x/page/b3237i1xkud.html
搜狐视频: https://tv.sohu.com/v/dXMvMzQ0NzUwMzM5LzI0ODA0MDMzOC5zaHRtbA==.html
共1 条记录, 每页显示 100 条, 页签: [1]

Copyright © 2000 - 2008 Dvbbs.Net  备案号:粤ICP备13014873号
Powered By Dvbbs Version 8.3.0
Processed in .06055 s, 2 queries.