New v5 MRP bug!

Sure... that's what I did.

Lydia Coffman wrote:
>
> Joe: In the meantime, can't you tell everyone that makes jobs NOT TO USE
> UF? We have standard prefixes that are acceptable here, and people have
> been told not to use anything else. This helps us with job tracking and
> even some reporting ("Job number begins RMA*).
>
> Just an idea.
>
> Lydia
>
> -----Original Message-----
> From: Joe Konecny [mailto:jkonecn@...]
> Sent: Thursday, February 15, 2001 5:57 AM
> To: vantage@yahoogroups.com
> Subject: Re: [Vantage] new v5 MRP bug!
>
> I have found out what is causing this problem. There is no
> error checking in the "run MRP" program that would check
> for an existing job of the same number that MRP is trying
> to create. We have a job numbered U99472 and MRP tries
> to create U0000000099472 and crashes. I had to change
> the unfirm prefix in MRP config to UF and it will run.
> This will be ok till someone inadvertently manually enters
> a job starting with UF. Then it will crash again.
> I suppose I'll need to request an "enhancement".
>
> Joe Konecny wrote:
> >
> > Here's a serious MRP bug that I found today. Epicor removed
> > the v4 feature that let you enter a job prefix when you run
> > MRP. If you want that feature you have to enter it in the
> > company config. Then it is set the same for every MRP run.
> > I don't like that but I can live with it. Problem is...
> > If you enter a prefix in the company config... MRP will
> > not run. We have a job number length of 6 set in job
> > management. MRP tries to assign the first job job number
> > U0000000099472. Then the next job it tries to assign the
> > same number and stops with an error message. "JobHead already
> > exists with company 'GMI' and jobnum 'U0000000099472'. The
> > only option is to not use the unfirm prefix in company config.
> >
> > Furthermore... there is a setting in MRP config called FIRM
> > prefix. Entering something here is supposed to be added to
> > any manually created job. This doesn't work at all.
> >
> > Version 5 has either not been through serious testing at
> > Epicor or it has and they pushed it out the door to meet
> > a deadline.
> >
> > I can't stress enough... Don't upgrade to v5 yet unless
> > you are willing to deal with loads of headaches.
> >
> >
> > To unsubscribe from this group, send an email to:
> > vantage-unsubscribe@egroups.com
>
> To unsubscribe from this group, send an email to:
> vantage-unsubscribe@egroups.com
>
>
> To unsubscribe from this group, send an email to:
> vantage-unsubscribe@egroups.com
Here's a serious MRP bug that I found today. Epicor removed
the v4 feature that let you enter a job prefix when you run
MRP. If you want that feature you have to enter it in the
company config. Then it is set the same for every MRP run.
I don't like that but I can live with it. Problem is...
If you enter a prefix in the company config... MRP will
not run. We have a job number length of 6 set in job
management. MRP tries to assign the first job job number
U0000000099472. Then the next job it tries to assign the
same number and stops with an error message. "JobHead already
exists with company 'GMI' and jobnum 'U0000000099472'. The
only option is to not use the unfirm prefix in company config.

Furthermore... there is a setting in MRP config called FIRM
prefix. Entering something here is supposed to be added to
any manually created job. This doesn't work at all.

Version 5 has either not been through serious testing at
Epicor or it has and they pushed it out the door to meet
a deadline.

I can't stress enough... Don't upgrade to v5 yet unless
you are willing to deal with loads of headaches.
I thought this element of MRP was for when you check a job as firm under
"Job Status Maintenance", the system would change the MRP job number to the
next actual job number and add this prefix. I tested this at the hall of
solutions at the perspectives conference. I don't' think it was intended for
manually entering jobs. Give this a try? Be sure to check the last job
entered before you do, it's kind of a voodoo move. Maybe the system should
add a MEMO to the job when this happens to document it. Some one might ask
what happened to Job MRP000000123 this morning, someone could have firmed it
up making it Z90001, you could find it in timephase, etc.. but it would be
nice to see a MEMO at 10:00am in the morning and who did it.

Patrick Winter

-----Original Message-----
From: Joe Konecny [mailto:jkonecn@...]
Sent: Wednesday, February 14, 2001 7:36 AM
To: Vantage List
Subject: [Vantage] new v5 MRP bug!


Furthermore... there is a setting in MRP config called FIRM
prefix. Entering something here is supposed to be added to
any manually created job. This doesn't work at all.



To unsubscribe from this group, send an email to:
vantage-unsubscribe@egroups.com
The "help" for the MRP setting in company config states:

"Firm Job prefix is the prefix assigned to a manually entered
job. Enter the applicable Firm Job prefix here, if any."

That would be ok if it worked that way you describe. Unfortunately MRP
won't run with an UNFIRM prefix to test it.

"Winter, Patrick" wrote:
>
> I thought this element of MRP was for when you check a job as firm under
> "Job Status Maintenance", the system would change the MRP job number to the
> next actual job number and add this prefix. I tested this at the hall of
> solutions at the perspectives conference. I don't' think it was intended for
> manually entering jobs. Give this a try? Be sure to check the last job
> entered before you do, it's kind of a voodoo move. Maybe the system should
> add a MEMO to the job when this happens to document it. Some one might ask
> what happened to Job MRP000000123 this morning, someone could have firmed it
> up making it Z90001, you could find it in timephase, etc.. but it would be
> nice to see a MEMO at 10:00am in the morning and who did it.
>
> Patrick Winter
>
> -----Original Message-----
> From: Joe Konecny [mailto:jkonecn@...]
> Sent: Wednesday, February 14, 2001 7:36 AM
> To: Vantage List
> Subject: [Vantage] new v5 MRP bug!
>
> Furthermore... there is a setting in MRP config called FIRM
> prefix. Entering something here is supposed to be added to
> any manually created job. This doesn't work at all.
>
> To unsubscribe from this group, send an email to:
> vantage-unsubscribe@egroups.com
>
>
> To unsubscribe from this group, send an email to:
> vantage-unsubscribe@egroups.com
Clarification:

The unfirm job number uses the "unfirm prefix followed by the next number in
the system. Once you "manually" firm the job up, the unfirm job number is
replaced with a firm job number and a "firm prefix" which can be different
than the unfirm prefix.

Patrick was on the correct path. We threw Joe off with the wording in help.
I admit, this is confusing and a request has already been submitted by
support to change the wording.

Joe, try checking the Process MRP box on a part, create a firm, and an
unfirm prefix in system configuration, create a sales order for the part,
run MRP. Look in job entry under unfirm jobs. An unfirm job will be created
using the unfirm prefix.
Now firm the job up by checking the firm check box. You should see the job
number change to the next system generated job number proceeded by a firm
prefix.

Hope this helps.



Michael Holton
e p i c o r S o f t w a r e
Customer Account Manager
Manufacturing Systems
(800)638-3208 Ext. 5242
www.epicor.com <http://www.epicor.com/>

-----Original Message-----
From: Winter, Patrick [mailto:pjw@...]
Sent: Wednesday, February 14, 2001 7:57 AM
To: 'vantage@yahoogroups.com'
Subject: RE: [Vantage] new v5 MRP bug!

I thought this element of MRP was for when you check a job as firm under
"Job Status Maintenance", the system would change the MRP job number to the
next actual job number and add this prefix. I tested this at the hall of
solutions at the perspectives conference. I don't' think it was intended for
manually entering jobs. Give this a try? Be sure to check the last job
entered before you do, it's kind of a voodoo move. Maybe the system should
add a MEMO to the job when this happens to document it. Some one might ask
what happened to Job MRP000000123 this morning, someone could have firmed it
up making it Z90001, you could find it in timephase, etc.. but it would be
nice to see a MEMO at 10:00am in the morning and who did it.

Patrick Winter

-----Original Message-----
From: Joe Konecny [mailto:jkonecn@...]
Sent: Wednesday, February 14, 2001 7:36 AM
To: Vantage List
Subject: [Vantage] new v5 MRP bug!


Furthermore... there is a setting in MRP config called FIRM
prefix. Entering something here is supposed to be added to
any manually created job. This doesn't work at all.



To unsubscribe from this group, send an email to:
vantage-unsubscribe@egroups.com






Yahoo! Groups Sponsor


<http://rd.yahoo.com/M=176325.1307934.2900314.1248726/D=egroupmail/S=1700007
183:N/A=567174/R=0/*http://domains.yahoo.com/>


<http://us.adserver.yahoo.com/l?M=176325.1307934.2900314.1248726/D=egroupmai
l/S=1700007183:N/A=567174/rand=419978463>

To unsubscribe from this group, send an email to:
vantage-unsubscribe@egroups.com




[Non-text portions of this message have been removed]
I have found out what is causing this problem. There is no
error checking in the "run MRP" program that would check
for an existing job of the same number that MRP is trying
to create. We have a job numbered U99472 and MRP tries
to create U0000000099472 and crashes. I had to change
the unfirm prefix in MRP config to UF and it will run.
This will be ok till someone inadvertently manually enters
a job starting with UF. Then it will crash again.
I suppose I'll need to request an "enhancement".

Joe Konecny wrote:
>
> Here's a serious MRP bug that I found today. Epicor removed
> the v4 feature that let you enter a job prefix when you run
> MRP. If you want that feature you have to enter it in the
> company config. Then it is set the same for every MRP run.
> I don't like that but I can live with it. Problem is...
> If you enter a prefix in the company config... MRP will
> not run. We have a job number length of 6 set in job
> management. MRP tries to assign the first job job number
> U0000000099472. Then the next job it tries to assign the
> same number and stops with an error message. "JobHead already
> exists with company 'GMI' and jobnum 'U0000000099472'. The
> only option is to not use the unfirm prefix in company config.
>
> Furthermore... there is a setting in MRP config called FIRM
> prefix. Entering something here is supposed to be added to
> any manually created job. This doesn't work at all.
>
> Version 5 has either not been through serious testing at
> Epicor or it has and they pushed it out the door to meet
> a deadline.
>
> I can't stress enough... Don't upgrade to v5 yet unless
> you are willing to deal with loads of headaches.
>
>
> To unsubscribe from this group, send an email to:
> vantage-unsubscribe@egroups.com
Joe: In the meantime, can't you tell everyone that makes jobs NOT TO USE
UF? We have standard prefixes that are acceptable here, and people have
been told not to use anything else. This helps us with job tracking and
even some reporting ("Job number begins RMA*).

Just an idea.

Lydia


-----Original Message-----
From: Joe Konecny [mailto:jkonecn@...]
Sent: Thursday, February 15, 2001 5:57 AM
To: vantage@yahoogroups.com
Subject: Re: [Vantage] new v5 MRP bug!

I have found out what is causing this problem. There is no
error checking in the "run MRP" program that would check
for an existing job of the same number that MRP is trying
to create. We have a job numbered U99472 and MRP tries
to create U0000000099472 and crashes. I had to change
the unfirm prefix in MRP config to UF and it will run.
This will be ok till someone inadvertently manually enters
a job starting with UF. Then it will crash again.
I suppose I'll need to request an "enhancement".

Joe Konecny wrote:
>
> Here's a serious MRP bug that I found today. Epicor removed
> the v4 feature that let you enter a job prefix when you run
> MRP. If you want that feature you have to enter it in the
> company config. Then it is set the same for every MRP run.
> I don't like that but I can live with it. Problem is...
> If you enter a prefix in the company config... MRP will
> not run. We have a job number length of 6 set in job
> management. MRP tries to assign the first job job number
> U0000000099472. Then the next job it tries to assign the
> same number and stops with an error message. "JobHead already
> exists with company 'GMI' and jobnum 'U0000000099472'. The
> only option is to not use the unfirm prefix in company config.
>
> Furthermore... there is a setting in MRP config called FIRM
> prefix. Entering something here is supposed to be added to
> any manually created job. This doesn't work at all.
>
> Version 5 has either not been through serious testing at
> Epicor or it has and they pushed it out the door to meet
> a deadline.
>
> I can't stress enough... Don't upgrade to v5 yet unless
> you are willing to deal with loads of headaches.
>
>
> To unsubscribe from this group, send an email to:
> vantage-unsubscribe@egroups.com


To unsubscribe from this group, send an email to:
vantage-unsubscribe@egroups.com