EPICOR 607A +: MRP and two MOMs in system

Yahoo Archive
1

MRP can only create a demand on an approved rev. Even if the part is the same, only the approved rev is allowed to create the demand.

 

Michael Brown

Master Scheduler / Programmer

D&S Manufacturing

715-284-5376 Ext. 344

 

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of Miguel Santillan
Sent: Thursday, October 03, 2013 04:08 PM MIKE
To: vantage@yahoogroups.com
Subject: [Vantage] EPICOR 607A +: MRP and two MOMs in system

 

 

We are running into an issue.

 

Part 1 Rev A is approved with a MOM.

 

Customer is ordering Part 1 Rev B which is in the process of quoting, typically we get the business.

 

SO is not direct byt MTS.

 

When MRP runs, it sees that Part 1 has a demand but releases a job for Rev A because Rev B is not approved yet.  We dont catch this until shipment where our labels indicate there is a mismatch.

 

Is this typical behavior for MRP?  My demand is for Rev B but still creates a job for REv A?

 

Miguel A. Santillan

ERP Analyst

Compass Manufacturing Systems

510-661-6666  Office

510-656-0603  Fax

msantillan@...

 

2

We are running into an issue.

 

Part 1 Rev A is approved with a MOM.

 

Customer is ordering Part 1 Rev B which is in the process of quoting, typically we get the business.

 

SO is not direct byt MTS.

 

When MRP runs, it sees that Part 1 has a demand but releases a job for Rev A because Rev B is not approved yet.  We dont catch this until shipment where our labels indicate there is a mismatch.

 

Is this typical behavior for MRP?  My demand is for Rev B but still creates a job for REv A?

 

Miguel A. Santillan

ERP Analyst

Compass Manufacturing Systems

510-661-6666  Office

510-656-0603  Fax

msantillan@...

 

3
Your demand comes from the rev on the sales order line. If the latest approved Rev is A, your demand will be for Rev A as it looks for the latest approved revision with the most recent effective date. If you want to go ahead and have MRP plan to Revision B, even though it is not approved, you can manually override the rev on the sales order line/rev field and it will plan to that Rev

From: Miguel Santillan <msantillan@...>
To: "vantage@yahoogroups.com" <vantage@yahoogroups.com>
Sent: Thursday, October 3, 2013 5:08 PM
Subject: [Vantage] EPICOR 607A +: MRP and two MOMs in system

  
<div id="ygrps-yiv-695241108yiv3165355445ygrp-text">
  
  
  <div>
We are running into an issue.
 
Part 1 Rev A is approved with a MOM.
 
Customer is ordering Part 1 Rev B which is in the process of quoting, typically we get the business.
 
SO is not direct byt MTS.
 
When MRP runs, it sees that Part 1 has a demand but releases a job for Rev A because Rev B is not approved yet.  We dont catch this until shipment where our labels indicate there is a mismatch.
 
Is this typical behavior for MRP?  My demand is for Rev B but still creates a job for REv A?
 
Miguel A. Santillan
ERP Analyst
Compass Manufacturing Systems
510-661-6666  Office
510-656-0603  Fax
 
</div>
 


<div style="color:#fff;height:0;"></div></div>
#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 #ygrps-yiv-695241108yiv3165355445 -- #ygrps-yiv-695241108yiv3165355445ygrp-mkp { border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 #ygrps-yiv-695241108yiv3165355445ygrp-mkp hr {
border:1px solid #d8d8d8;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 #ygrps-yiv-695241108yiv3165355445ygrp-mkp #ygrps-yiv-695241108yiv3165355445hd {
color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 0;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 #ygrps-yiv-695241108yiv3165355445ygrp-mkp #ygrps-yiv-695241108yiv3165355445ads {
margin-bottom:10px;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 #ygrps-yiv-695241108yiv3165355445ygrp-mkp .ygrps-yiv-695241108yiv3165355445ad {
padding:0 0;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 #ygrps-yiv-695241108yiv3165355445ygrp-mkp .ygrps-yiv-695241108yiv3165355445ad p {
margin:0;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 #ygrps-yiv-695241108yiv3165355445ygrp-mkp .ygrps-yiv-695241108yiv3165355445ad a {
color:#0000ff;text-decoration:none;}
#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 #ygrps-yiv-695241108yiv3165355445ygrp-sponsor #ygrps-yiv-695241108yiv3165355445ygrp-lc {
font-family:Arial;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 #ygrps-yiv-695241108yiv3165355445ygrp-sponsor #ygrps-yiv-695241108yiv3165355445ygrp-lc #ygrps-yiv-695241108yiv3165355445hd {
margin:10px 0px;font-weight:700;font-size:78%;line-height:122%;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 #ygrps-yiv-695241108yiv3165355445ygrp-sponsor #ygrps-yiv-695241108yiv3165355445ygrp-lc .ygrps-yiv-695241108yiv3165355445ad {
margin-bottom:10px;padding:0 0;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 #ygrps-yiv-695241108yiv3165355445actions {
font-family:Verdana;font-size:11px;padding:10px 0;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 #ygrps-yiv-695241108yiv3165355445activity {
background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 #ygrps-yiv-695241108yiv3165355445activity span {
font-weight:700;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 #ygrps-yiv-695241108yiv3165355445activity span:first-child {
text-transform:uppercase;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 #ygrps-yiv-695241108yiv3165355445activity span a {
color:#5085b6;text-decoration:none;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 #ygrps-yiv-695241108yiv3165355445activity span span {
color:#ff7900;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 #ygrps-yiv-695241108yiv3165355445activity span .ygrps-yiv-695241108yiv3165355445underline {
text-decoration:underline;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 .ygrps-yiv-695241108yiv3165355445attach {
clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 0;width:400px;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 .ygrps-yiv-695241108yiv3165355445attach div a {
text-decoration:none;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 .ygrps-yiv-695241108yiv3165355445attach img {
border:none;padding-right:5px;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 .ygrps-yiv-695241108yiv3165355445attach label {
display:block;margin-bottom:5px;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 .ygrps-yiv-695241108yiv3165355445attach label a {
text-decoration:none;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 blockquote {
margin:0 0 0 4px;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 .ygrps-yiv-695241108yiv3165355445bold {
font-family:Arial;font-size:13px;font-weight:700;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 .ygrps-yiv-695241108yiv3165355445bold a {
text-decoration:none;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 dd.ygrps-yiv-695241108yiv3165355445last p a {
font-family:Verdana;font-weight:700;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 dd.ygrps-yiv-695241108yiv3165355445last p span {
margin-right:10px;font-family:Verdana;font-weight:700;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 dd.ygrps-yiv-695241108yiv3165355445last p span.ygrps-yiv-695241108yiv3165355445yshortcuts {
margin-right:0;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 div.ygrps-yiv-695241108yiv3165355445attach-table div div a {
text-decoration:none;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 div.ygrps-yiv-695241108yiv3165355445attach-table {
width:400px;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 div.ygrps-yiv-695241108yiv3165355445file-title a, #ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 div.ygrps-yiv-695241108yiv3165355445file-title a:active, #ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 div.ygrps-yiv-695241108yiv3165355445file-title a:hover, #ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 div.ygrps-yiv-695241108yiv3165355445file-title a:visited {
text-decoration:none;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 div.ygrps-yiv-695241108yiv3165355445photo-title a, #ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 div.ygrps-yiv-695241108yiv3165355445photo-title a:active, #ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 div.ygrps-yiv-695241108yiv3165355445photo-title a:hover, #ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 div.ygrps-yiv-695241108yiv3165355445photo-title a:visited {
text-decoration:none;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 div#ygrps-yiv-695241108yiv3165355445ygrp-mlmsg #ygrps-yiv-695241108yiv3165355445ygrp-msg p a span.ygrps-yiv-695241108yiv3165355445yshortcuts {
font-family:Verdana;font-size:10px;font-weight:normal;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 .ygrps-yiv-695241108yiv3165355445green {
color:#628c2a;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 .ygrps-yiv-695241108yiv3165355445MsoNormal {
margin:0 0 0 0;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 o {
font-size:0;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 #ygrps-yiv-695241108yiv3165355445photos div {
float:left;width:72px;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 #ygrps-yiv-695241108yiv3165355445photos div div {
border:1px solid #666666;height:62px;overflow:hidden;width:62px;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 #ygrps-yiv-695241108yiv3165355445photos div label {
color:#666666;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 #ygrps-yiv-695241108yiv3165355445reco-category {
font-size:77%;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 #ygrps-yiv-695241108yiv3165355445reco-desc {
font-size:77%;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 .ygrps-yiv-695241108yiv3165355445replbq {
margin:4px;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 #ygrps-yiv-695241108yiv3165355445ygrp-actbar div a:first-child {
margin-right:2px;padding-right:5px;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 #ygrps-yiv-695241108yiv3165355445ygrp-mlmsg {
font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 #ygrps-yiv-695241108yiv3165355445ygrp-mlmsg table {
font-size:inherit;font:100%;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 #ygrps-yiv-695241108yiv3165355445ygrp-mlmsg select, #ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 input, #ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 textarea {
font:99% Arial, Helvetica, clean, sans-serif;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 #ygrps-yiv-695241108yiv3165355445ygrp-mlmsg pre, #ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 code {
font:115% monospace;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 #ygrps-yiv-695241108yiv3165355445ygrp-mlmsg * {
line-height:1.22em;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 #ygrps-yiv-695241108yiv3165355445ygrp-mlmsg #ygrps-yiv-695241108yiv3165355445logo {
padding-bottom:10px;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 #ygrps-yiv-695241108yiv3165355445ygrp-msg p a {
font-family:Verdana;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 #ygrps-yiv-695241108yiv3165355445ygrp-msg p#ygrps-yiv-695241108yiv3165355445attach-count span {
color:#1E66AE;font-weight:700;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 #ygrps-yiv-695241108yiv3165355445ygrp-reco #ygrps-yiv-695241108yiv3165355445reco-head {
color:#ff7900;font-weight:700;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 #ygrps-yiv-695241108yiv3165355445ygrp-reco {
margin-bottom:20px;padding:0px;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 #ygrps-yiv-695241108yiv3165355445ygrp-sponsor #ygrps-yiv-695241108yiv3165355445ov li a {
font-size:130%;text-decoration:none;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 #ygrps-yiv-695241108yiv3165355445ygrp-sponsor #ygrps-yiv-695241108yiv3165355445ov li {
font-size:77%;list-style-type:square;padding:6px 0;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 #ygrps-yiv-695241108yiv3165355445ygrp-sponsor #ygrps-yiv-695241108yiv3165355445ov ul {
margin:0;padding:0 0 0 8px;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 #ygrps-yiv-695241108yiv3165355445ygrp-text {
font-family:Georgia;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 #ygrps-yiv-695241108yiv3165355445ygrp-text p {
margin:0 0 1em 0;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 #ygrps-yiv-695241108yiv3165355445ygrp-text tt {
font-size:120%;}

#ygrps-yiv-695241108 #ygrps-yiv-695241108yiv3165355445 #ygrps-yiv-695241108yiv3165355445ygrp-vital ul li:last-child {
border-right:none !important;}
#ygrps-yiv-695241108



4

Our Sales Order does indicate Part 1 Rev B.  That is why we dont understand why Rev A is being created though the SO Line states REv B.

 

Miguel A. Santillan

Compass Manufacturing Systems

510-661-6666  Office

 

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of Mark Wagner
Sent: Thursday, October 03, 2013 2:45 PM
To: vantage@yahoogroups.com
Subject: Re: [Vantage] EPICOR 607A +: MRP and two MOMs in system

 

 

Your demand comes from the rev on the sales order line. If the latest approved Rev is A, your demand will be for Rev A as it looks for the latest approved revision with the most recent effective date. If you want to go ahead and have MRP plan to Revision B, even though it is not approved, you can manually override the rev on the sales order line/rev field and it will plan to that Rev

 

From: Miguel Santillan <msantillan@...>
To: "vantage@yahoogroups.com" <vantage@yahoogroups.com>
Sent: Thursday, October 3, 2013 5:08 PM
Subject: [Vantage] EPICOR 607A +: MRP and two MOMs in system

 

 

We are running into an issue.

 

Part 1 Rev A is approved with a MOM.

 

Customer is ordering Part 1 Rev B which is in the process of quoting, typically we get the business.

 

SO is not direct byt MTS.

 

When MRP runs, it sees that Part 1 has a demand but releases a job for Rev A because Rev B is not approved yet.  We dont catch this until shipment where our labels indicate there is a mismatch.

 

Is this typical behavior for MRP?  My demand is for Rev B but still creates a job for REv A?

 

Miguel A. Santillan

ERP Analyst

Compass Manufacturing Systems

510-661-6666  Office

510-656-0603  Fax

 

 

5

I believe the 'Use Part Rev' checkbox on Part Maintenance controls this functionality.  If checked, the system will use the approved revision with the latest effective date, as described by Mark, overriding what's specified on the order.  If you want the system to plan that revision which is specified on the order, then clear the 'Use Part Rev' checkbox.

 

Most likely, though, you won't get a job until the revision is finally approved.  I would recommend testing to see if no job is created or if you get an empty job.

 

Bob Beaghan



---In vantage@yahoogroups.com, <msantillan@...> wrote:

Our Sales Order does indicate Part 1 Rev B.  That is why we dont understand why Rev A is being created though the SO Line states REv B.

 

Miguel A. Santillan

Compass Manufacturing Systems

510-661-6666  Office

 

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of Mark Wagner
Sent: Thursday, October 03, 2013 2:45 PM
To: vantage@yahoogroups.com
Subject: Re: [Vantage] EPICOR 607A +: MRP and two MOMs in system

 

 

Your demand comes from the rev on the sales order line. If the latest approved Rev is A, your demand will be for Rev A as it looks for the latest approved revision with the most recent effective date. If you want to go ahead and have MRP plan to Revision B, even though it is not approved, you can manually override the rev on the sales order line/rev field and it will plan to that Rev

 

From: Miguel Santillan <msantillan@...>
To: "vantage@yahoogroups.com" <vantage@yahoogroups.com>
Sent: Thursday, October 3, 2013 5:08 PM
Subject: [Vantage] EPICOR 607A +: MRP and two MOMs in system

 

 

We are running into an issue.

 

Part 1 Rev A is approved with a MOM.

 

Customer is ordering Part 1 Rev B which is in the process of quoting, typically we get the business.

 

SO is not direct byt MTS.

 

When MRP runs, it sees that Part 1 has a demand but releases a job for Rev A because Rev B is not approved yet.  We dont catch this until shipment where our labels indicate there is a mismatch.

 

Is this typical behavior for MRP?  My demand is for Rev B but still creates a job for REv A?

 

Miguel A. Santillan

ERP Analyst

Compass Manufacturing Systems

510-661-6666  Office

510-656-0603  Fax