MRP and scheduling

Yahoo Archive
1
Thanks Bill. Looks like you are running things very similar to us.

Now that we are running things as a three step, MRP, Global Scheduling Order, then Global Scheduling, we haven't had a lockup. We also found running only 1 process for each step works better too. Takes a bit longer, but we are still less than an hour to complete everything using regen.

--- In vantage@yahoogroups.com, "Bill" <wmitchell@...> wrote:
>
> 1. How long does MRP take to run, using a) Regenerative b) Net Change?
> Never use net change, always regen. Its run Mon to Thurs early morning. It takes about 30 mins to run. We have about 6000 parts on the system and BOMs are generally no more than 5 or 6 levels.
>
> 3. Yes we use finite scheduling
>
> 4. 1 process for MRP and 1 scheduler
>
> 5. We do occasionally get lock ups. As part of the daily tasks we check the appserver for stuck processes, deleting those usually clears things.
>
> 7. We log MRP and schedule activity
>
> 8. Parts are constrained.
>
> Any other issues ? Is anyone aware of a third party scheduling tool which interfaces with Vantage (we run 8.03.408) ?
> Our experience with MRP is mixed to say the least. Initially it produced vast volumes of spurious suggestions which with the help of an outside consultant we eventually managed to resolve, however it still leaves us scratching our heads at times.
> Do people in this forum use the scheduling boards ? Or do you have something else that can be used to manipulate data in a similar sort of graphical way ?
>
> Thanks
>
> Bill
>
>
>
>
>
> --- In vantage@yahoogroups.com, "Tim Vonderhaar" <tvonderhaar@> wrote:
> >
> > We are running some pilot MRP tests and are struggling a bit to understand if things are working as expected. We are reading through the MRP Tech Ref Guide, but would like to know what others have actually experienced in their organization. I understand that this isn't a one size fits all thing, but would like to get a few points of reference.
> >
> > 1) How long does MRP take to run, using a) Regenerative b) Net Change?
> > 2) How often do you run Regenerative?
> > 3) Do you use Finite Scheduling?
> > 4) What number of MRP processes do you use?
> > 5) What number of schedulers do you use?
> > 6) Have you ever had the MRP process lock up? If so, how can one tell?
> > 7) Do you use logging? If so, what setting do you use? a) basic b) MRP c) MRP and Scheduling?
> > 8) Are your parts constrained?
> > 9) Do you use APS?
> > 10) Any lessons learned?
> >
> > Thanks,
> > Tim
> >
>
2
We are running some pilot MRP tests and are struggling a bit to understand if things are working as expected. We are reading through the MRP Tech Ref Guide, but would like to know what others have actually experienced in their organization. I understand that this isn't a one size fits all thing, but would like to get a few points of reference.

1) How long does MRP take to run, using a) Regenerative b) Net Change?
2) How often do you run Regenerative?
3) Do you use Finite Scheduling?
4) What number of MRP processes do you use?
5) What number of schedulers do you use?
6) Have you ever had the MRP process lock up? If so, how can one tell?
7) Do you use logging? If so, what setting do you use? a) basic b) MRP c) MRP and Scheduling?
8) Are your parts constrained?
9) Do you use APS?
10) Any lessons learned?

Thanks,
Tim
3
We have been running MRP for about 6 years. We have had some bad experiences with it but most of that was caused by too little processing power. When we first started running MRP on a 32 bit Windows 2003 Standard with 4GB of memory it was taking 13 hours to run a REGEN and about 2 hours to run a Net Change. Because of time constraints we only ran REGEN on the weekend. At that time we had about 57,000 parts in the systems and a job backlog of 10-12 months. We ran MRP out 7 months to catch parts with 6 months lead time. Eventually with upgrades to Vantage our MRP processing time was cut down to about 8 hours for a REGEN. FYI, at that time were were building about 30 - 40 units a month with each unit having 11 levels of about 1700 parts. We were told this machine was good enough but soon found out it was not.

We ran that way for about 2 years and then upgraded the server to 64bit Windows 2003 Standard with 32GB of memory with two dual core Xeon processors. A MRP REGEN went from 8 hours to a little under 2 hours. Knowing this I can say for sure that you do need to ensure you do not skimp on hardware or memory. A 64bit operating system is an absolute must. With that number of cores and processors MRP would take from 20% to 80% of the processing power of the machine. We have since upgraded the server to one with dual 6 core Xeons with hyper theading. That now gives 24 processors. MRP now only takes about 3% of processing power. One thing to note about a REGEN, the first thing it does is to delete all on the un-firmed jobs. During that deletion process the machine is unusable because of disk access and that is with 15k SCSI drives in a Raid 10 configuration. The new machine did not cut down on the MRP processing time but it did allow use of the machine during it runtime. We can now run a Net Change during the day without any disruption to the users. We are currently running version 8.03.408b but working on upgrading to Epicor 9.05.xxx by 2013.

We do not do Finite scheduling nor are our parts constrained. We do not use APS. We run one MRP process and one scheduler. If we tried to run more that one of each MRP would lock up on us about 90% of the time. I have not tried using more in quite some time and it might work now but with the short time it takes MRP to run I don't see any use in running the risk. Even when MRP did not lock up when we were running more that one MRP process and/or schedulers I did not see that it saved a significant amount of time. That was probably caused because the machine did not have enough processing power. We use logging and it is set to MRP. The reason for this is to catch any errors that cause an assembly or unit to not be scheduled because of errors in the BOM (usually caused by an unapproved assembly). You only have to search the log for the word "assembly" to find any errors.

We had MRP lock up on us a lot when we first started using it. We had to train our engineers to stop adding new assemblies, make it a component of a current BOM, make it effective immediately and leaving it unapproved. That combination would lock up MRP every time. Once the engineers changed their procedures we have not had MRP lockup on use but one time in the last two years. That lockup was caused by the combination above; we just had an engineer forget the proper procedure.

You are right that one size does not fit all. We found very quickly that the operating system, number of processors and memory are key factors. The number of parts, the complexity of your BOM and the number of jobs to be scheduled will determine the amount of processing power you will need. Knowing what I know now I would budget the best machine that I could afford and then try to upgrade that to a better one when I actually make the purchase. Of course, you also have to keep in mind the number of users you have as well. My advice for that is to get a much memory as you can afford. Keep in mind that 64bit Windows Standard will only see 32GB of memory. My last two servers have had 32GB of memory although we typically never use more than are 13GB. It never hurts to have more than you need and with the low cost of memory today there is no use in skimping.

If I made any sense to you then I hope I was some help. I am typing this with my wife and step-son right behind me talking about guitars and asking me questions.


Charles Carden
IT Manager
Manitex, Inc.
Georgetown, Texas
----- Original Message -----
From: Tim Vonderhaar
To: vantage@yahoogroups.com
Sent: Friday, November 11, 2011 12:10 PM
Subject: [Vantage] MRP and scheduling



We are running some pilot MRP tests and are struggling a bit to understand if things are working as expected. We are reading through the MRP Tech Ref Guide, but would like to know what others have actually experienced in their organization. I understand that this isn't a one size fits all thing, but would like to get a few points of reference.

1) How long does MRP take to run, using a) Regenerative b) Net Change?
2) How often do you run Regenerative?
3) Do you use Finite Scheduling?
4) What number of MRP processes do you use?
5) What number of schedulers do you use?
6) Have you ever had the MRP process lock up? If so, how can one tell?
7) Do you use logging? If so, what setting do you use? a) basic b) MRP c) MRP and Scheduling?
8) Are your parts constrained?
9) Do you use APS?
10) Any lessons learned?

Thanks,
Tim





[Non-text portions of this message have been removed]
4
Hi Tim,

Sounds like as Charles is using MRP almost exactly the same as I have except for:

>8.03.408b
-- 8.03.409C

>30 - 40 units a month with
-- 3 to 5 units a month - capital equipment - think warehouse sized
-- And also maintaining stock for replacement parts sales - maybe 1000 part numbers

>each unit having 11 levels of about 1700 parts.
-- Here it is more like 9 levels with 2400 component part numbers

>13 hours to run a REGEN and about
-- 20 minutes for a REGEN

>2 hours to run a Net Change.
-- 5 minutes for a NET change


We also do not run finite and don't have the modules required for constraining materials.

MRP - Net change is run daily to keep up with part sales.
MRP - Regen is run as needed, usually when a major "unit" is sold.

If MRP hasn't been run for a while because no ne demand from units - we might run Global Reschedule to refresh dates.

> You are right that one size does not fit all.
Individual parts in runs of 1000's or manufactured units with 1000's of components? Lot's of jobs with complicated methods or maybe lean towards more volume purchasing and sales? Are your resources dedicated and specialized or more general purpose?


--- In vantage@yahoogroups.com, "Charles Carden" <shadowcar1449@...> wrote:
>
> We have been running MRP for about 6 years. We have had some bad experiences with it but most of that was caused by too little processing power. When we first started running MRP on a 32 bit Windows 2003 Standard with 4GB of memory it was taking 13 hours to run a REGEN and about 2 hours to run a Net Change. Because of time constraints we only ran REGEN on the weekend. At that time we had about 57,000 parts in the systems and a job backlog of 10-12 months. We ran MRP out 7 months to catch parts with 6 months lead time. Eventually with upgrades to Vantage our MRP processing time was cut down to about 8 hours for a REGEN. FYI, at that time were were building about 30 - 40 units a month with each unit having 11 levels of about 1700 parts. We were told this machine was good enough but soon found out it was not.
>
> We ran that way for about 2 years and then upgraded the server to 64bit Windows 2003 Standard with 32GB of memory with two dual core Xeon processors. A MRP REGEN went from 8 hours to a little under 2 hours. Knowing this I can say for sure that you do need to ensure you do not skimp on hardware or memory. A 64bit operating system is an absolute must. With that number of cores and processors MRP would take from 20% to 80% of the processing power of the machine. We have since upgraded the server to one with dual 6 core Xeons with hyper theading. That now gives 24 processors. MRP now only takes about 3% of processing power. One thing to note about a REGEN, the first thing it does is to delete all on the un-firmed jobs. During that deletion process the machine is unusable because of disk access and that is with 15k SCSI drives in a Raid 10 configuration. The new machine did not cut down on the MRP processing time but it did allow use of the machine during it runtime. We can now run a Net Change during the day without any disruption to the users. We are currently running version 8.03.408b but working on upgrading to Epicor 9.05.xxx by 2013.
>
> We do not do Finite scheduling nor are our parts constrained. We do not use APS. We run one MRP process and one scheduler. If we tried to run more that one of each MRP would lock up on us about 90% of the time. I have not tried using more in quite some time and it might work now but with the short time it takes MRP to run I don't see any use in running the risk. Even when MRP did not lock up when we were running more that one MRP process and/or schedulers I did not see that it saved a significant amount of time. That was probably caused because the machine did not have enough processing power. We use logging and it is set to MRP. The reason for this is to catch any errors that cause an assembly or unit to not be scheduled because of errors in the BOM (usually caused by an unapproved assembly). You only have to search the log for the word "assembly" to find any errors.
>
> We had MRP lock up on us a lot when we first started using it. We had to train our engineers to stop adding new assemblies, make it a component of a current BOM, make it effective immediately and leaving it unapproved. That combination would lock up MRP every time. Once the engineers changed their procedures we have not had MRP lockup on use but one time in the last two years. That lockup was caused by the combination above; we just had an engineer forget the proper procedure.
>
> You are right that one size does not fit all. We found very quickly that the operating system, number of processors and memory are key factors. The number of parts, the complexity of your BOM and the number of jobs to be scheduled will determine the amount of processing power you will need. Knowing what I know now I would budget the best machine that I could afford and then try to upgrade that to a better one when I actually make the purchase. Of course, you also have to keep in mind the number of users you have as well. My advice for that is to get a much memory as you can afford. Keep in mind that 64bit Windows Standard will only see 32GB of memory. My last two servers have had 32GB of memory although we typically never use more than are 13GB. It never hurts to have more than you need and with the low cost of memory today there is no use in skimping.
>
> If I made any sense to you then I hope I was some help. I am typing this with my wife and step-son right behind me talking about guitars and asking me questions.
>
>
> Charles Carden
> IT Manager
> Manitex, Inc.
> Georgetown, Texas
> ----- Original Message -----
> From: Tim Vonderhaar
> To: vantage@yahoogroups.com
> Sent: Friday, November 11, 2011 12:10 PM
> Subject: [Vantage] MRP and scheduling
>
>
>
> We are running some pilot MRP tests and are struggling a bit to understand if things are working as expected. We are reading through the MRP Tech Ref Guide, but would like to know what others have actually experienced in their organization. I understand that this isn't a one size fits all thing, but would like to get a few points of reference.
>
> 1) How long does MRP take to run, using a) Regenerative b) Net Change?
> 2) How often do you run Regenerative?
> 3) Do you use Finite Scheduling?
> 4) What number of MRP processes do you use?
> 5) What number of schedulers do you use?
> 6) Have you ever had the MRP process lock up? If so, how can one tell?
> 7) Do you use logging? If so, what setting do you use? a) basic b) MRP c) MRP and Scheduling?
> 8) Are your parts constrained?
> 9) Do you use APS?
> 10) Any lessons learned?
>
> Thanks,
> Tim
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
5
We are using MRP on E9.04.507A, mostly successfully. We're still tweaking the purchasing side of things.

> 1) How long does MRP take to run, using a) Regenerative b) Net Change?

1. We run Net Change every night. Never run Regen, it just doesn't work for what we need to do. In our situation a Net Change takes between 3 and 4 hours, beginning at midnight (the plant is closed). As a point of comparison, a plant I used to work at ran 24 hours/5 days, and there we ran a Net Change on Sunday, but it took over 8 hours to run. So much depends on the type of parts, the complexities of the jobs, and the number of things MRP has to do.

> 2) How often do you run Regenerative?

2. Don't use Regen.

> 3) Do you use Finite Scheduling?

3. Not yet, but that is a future project. Most (vast majority) of jobs start and finish within a single day, and run through multiple operation stations... as currently constructed, it would take longer to manually enter labor than it would to complete the job. Labor is backflushed at the end.

> 4) What number of MRP processes do you use?
> 5) What number of schedulers do you use?

4/5. We use 4 MRP process and 2 Schedulers. This is completely dependent on your server hardware.

> 6) Have you ever had the MRP process lock up? If so, how can one tell?

6. We've never had it "lock up" (at least, to the best of my knowledge!), but it does seem to stop processing at random points. I'll look at the log and discover that the first 1500 jobs were created over the course of a couple of hours, then there will be a break of another hour with no file activity, then the rest of the jobs will get created and the process will finish. That issue hasn't percolated to the top of my "gotta get this fixed" list yet.

> 7) Do you use logging? If so, what setting do you use? a) basic b) MRP c) MRP and Scheduling?

7. I used the full MRP and Scheduling log. I have a batch file that automatically erases the log files each evening (before the next run), but I do know I have to fix the problem above so I create the logs in case it DOES percolate to the top.

> 8) Are your parts constrained?

8. No.

> 9) Do you use APS?

9. No

> 10) Any lessons learned?

10. Mainly this is not, and never will be, a "set it and forget it" process. We've recently begun adding customer forecasts, which has more than doubled the amount of time it takes to run every morning. Most recently we've been concentrating on removing noise from the Purchasing Suggestions, but that has other costs that both Production and Finance are starting to ask about.

If you've never used MRP before, your first few runs will find problems with BOMs and BOOs that you never knew existed... and they could be REAL problems. The two times I've been involved in and MRP implementation, Scheduling was taken out and made a separate project that would NOT be even looked at carefully until AFTER the MRP process was working acceptably.

Good Luck!

Ernie Lowell
Diba Industries
6
Thanks everyone for the input.

I have to say, I'm worried hearing about the temperamental nature of the MRP threads and things locking up. Such a fundamental part of an ERP system should be rock solid.

Our environment is pretty rough. We have a very broad product line with some units still running after being in service for 30 years. Unlike many companies today, we seem to never to be able to obsolete a product.

We have 45000 parts in our parts master with 24000 of them manufactured in house. 1/3 of our business is new, 1/3 is repair and 1/3 is spare parts. Our shop is mix of specialized and general purpose, very few are dedicated. We had to opt for the APS module to allow us to get around the single resource can only exist in a single resource group problem. We are small, only 45 employees, so the user count is low, but the manpower can be moved around to many different machines.

With our MRP testing so far, we have used 2 MRP and 2 schedule processes. We can run a Net Change is just a few minutes. A Regen never seems to complete. Watching the logs, it will get stuck on a job and the log for that will basically grow forever...over 700Meg... before we canceled the process. Even then, the log continued to grow and did so until we reset the app servers. Strangely, we could go back and schedule the job manually and it would complete, so not sure if we are dealing with a BOM problem or not. I have contacted Epicor but haven't heard back yet.

--- In vantage@yahoogroups.com, "Tim Vonderhaar" <tvonderhaar@...> wrote:
>
> We are running some pilot MRP tests and are struggling a bit to understand if things are working as expected. We are reading through the MRP Tech Ref Guide, but would like to know what others have actually experienced in their organization. I understand that this isn't a one size fits all thing, but would like to get a few points of reference.
>
> 1) How long does MRP take to run, using a) Regenerative b) Net Change?
> 2) How often do you run Regenerative?
> 3) Do you use Finite Scheduling?
> 4) What number of MRP processes do you use?
> 5) What number of schedulers do you use?
> 6) Have you ever had the MRP process lock up? If so, how can one tell?
> 7) Do you use logging? If so, what setting do you use? a) basic b) MRP c) MRP and Scheduling?
> 8) Are your parts constrained?
> 9) Do you use APS?
> 10) Any lessons learned?
>
> Thanks,
> Tim
>
7
Tom,

We have also had the problem of MRP looping. A suggestion that another user made was to uncheck the Run Finite Scheduling during MPR calculation. We then run Calculate Global Scheduling Order, then Global Scheduling. Since we made that change, we have not had a looping issue.

Richard L. Sirow, President
www.iccparts.com
rick@...

On Nov 14, 2011, at 9:49 AM, Tim Vonderhaar wrote:

> Thanks everyone for the input.
>
> I have to say, I'm worried hearing about the temperamental nature of the MRP threads and things locking up. Such a fundamental part of an ERP system should be rock solid.
>
> Our environment is pretty rough. We have a very broad product line with some units still running after being in service for 30 years. Unlike many companies today, we seem to never to be able to obsolete a product.
>
> We have 45000 parts in our parts master with 24000 of them manufactured in house. 1/3 of our business is new, 1/3 is repair and 1/3 is spare parts. Our shop is mix of specialized and general purpose, very few are dedicated. We had to opt for the APS module to allow us to get around the single resource can only exist in a single resource group problem. We are small, only 45 employees, so the user count is low, but the manpower can be moved around to many different machines.
>
> With our MRP testing so far, we have used 2 MRP and 2 schedule processes. We can run a Net Change is just a few minutes. A Regen never seems to complete. Watching the logs, it will get stuck on a job and the log for that will basically grow forever...over 700Meg... before we canceled the process. Even then, the log continued to grow and did so until we reset the app servers. Strangely, we could go back and schedule the job manually and it would complete, so not sure if we are dealing with a BOM problem or not. I have contacted Epicor but haven't heard back yet.
>
> --- In vantage@yahoogroups.com, "Tim Vonderhaar" <tvonderhaar@...> wrote:
> >
> > We are running some pilot MRP tests and are struggling a bit to understand if things are working as expected. We are reading through the MRP Tech Ref Guide, but would like to know what others have actually experienced in their organization. I understand that this isn't a one size fits all thing, but would like to get a few points of reference.
> >
> > 1) How long does MRP take to run, using a) Regenerative b) Net Change?
> > 2) How often do you run Regenerative?
> > 3) Do you use Finite Scheduling?
> > 4) What number of MRP processes do you use?
> > 5) What number of schedulers do you use?
> > 6) Have you ever had the MRP process lock up? If so, how can one tell?
> > 7) Do you use logging? If so, what setting do you use? a) basic b) MRP c) MRP and Scheduling?
> > 8) Are your parts constrained?
> > 9) Do you use APS?
> > 10) Any lessons learned?
> >
> > Thanks,
> > Tim
> >
>
>



[Non-text portions of this message have been removed]
8
We have issues with MRP locking up only when users are doing anything in epicor while it runs. I noticed everything is pegged out while it runs no Proc left and only about 20% mem left. Is there a way to know if MRP is finishing correctly though? We are in piloting, so no normal users entering the system, and it seems even within 20 minutes of running MRP we get different results each time. What is the major difference between regen and net change? All I know is regen removed existing unfirm MRP jobs and reproduces them along with PO suggestions.

--- In vantage@yahoogroups.com, Sirow Richard <rick@...> wrote:
>
> Tom,
>
> We have also had the problem of MRP looping. A suggestion that another user made was to uncheck the Run Finite Scheduling during MPR calculation. We then run Calculate Global Scheduling Order, then Global Scheduling. Since we made that change, we have not had a looping issue.
>
> Richard L. Sirow, President
> www.iccparts.com
> rick@...
>
> On Nov 14, 2011, at 9:49 AM, Tim Vonderhaar wrote:
>
> > Thanks everyone for the input.
> >
> > I have to say, I'm worried hearing about the temperamental nature of the MRP threads and things locking up. Such a fundamental part of an ERP system should be rock solid.
> >
> > Our environment is pretty rough. We have a very broad product line with some units still running after being in service for 30 years. Unlike many companies today, we seem to never to be able to obsolete a product.
> >
> > We have 45000 parts in our parts master with 24000 of them manufactured in house. 1/3 of our business is new, 1/3 is repair and 1/3 is spare parts. Our shop is mix of specialized and general purpose, very few are dedicated. We had to opt for the APS module to allow us to get around the single resource can only exist in a single resource group problem. We are small, only 45 employees, so the user count is low, but the manpower can be moved around to many different machines.
> >
> > With our MRP testing so far, we have used 2 MRP and 2 schedule processes. We can run a Net Change is just a few minutes. A Regen never seems to complete. Watching the logs, it will get stuck on a job and the log for that will basically grow forever...over 700Meg... before we canceled the process. Even then, the log continued to grow and did so until we reset the app servers. Strangely, we could go back and schedule the job manually and it would complete, so not sure if we are dealing with a BOM problem or not. I have contacted Epicor but haven't heard back yet.
> >
> > --- In vantage@yahoogroups.com, "Tim Vonderhaar" <tvonderhaar@> wrote:
> > >
> > > We are running some pilot MRP tests and are struggling a bit to understand if things are working as expected. We are reading through the MRP Tech Ref Guide, but would like to know what others have actually experienced in their organization. I understand that this isn't a one size fits all thing, but would like to get a few points of reference.
> > >
> > > 1) How long does MRP take to run, using a) Regenerative b) Net Change?
> > > 2) How often do you run Regenerative?
> > > 3) Do you use Finite Scheduling?
> > > 4) What number of MRP processes do you use?
> > > 5) What number of schedulers do you use?
> > > 6) Have you ever had the MRP process lock up? If so, how can one tell?
> > > 7) Do you use logging? If so, what setting do you use? a) basic b) MRP c) MRP and Scheduling?
> > > 8) Are your parts constrained?
> > > 9) Do you use APS?
> > > 10) Any lessons learned?
> > >
> > > Thanks,
> > > Tim
> > >
> >
> >
>
>
>
> [Non-text portions of this message have been removed]
>
9
Tom, good luck with support for MRP. I have never had any luck with them at all. They always say nothing is wrong, hmmm that is hard for me to believe. Try running only 1 MRP process and 1 Scheduling process. That should take care of the lock ups. We were getting the same results you are getting until we changed to 1 and 1. We never could determine the problem either.

Charles Carden
IT Manager
Manitex, Inc.
Georgetown, Texas
----- Original Message -----
From: Tim Vonderhaar
To: vantage@yahoogroups.com
Sent: Monday, November 14, 2011 8:49 AM
Subject: [Vantage] Re: MRP and scheduling



Thanks everyone for the input.

I have to say, I'm worried hearing about the temperamental nature of the MRP threads and things locking up. Such a fundamental part of an ERP system should be rock solid.

Our environment is pretty rough. We have a very broad product line with some units still running after being in service for 30 years. Unlike many companies today, we seem to never to be able to obsolete a product.

We have 45000 parts in our parts master with 24000 of them manufactured in house. 1/3 of our business is new, 1/3 is repair and 1/3 is spare parts. Our shop is mix of specialized and general purpose, very few are dedicated. We had to opt for the APS module to allow us to get around the single resource can only exist in a single resource group problem. We are small, only 45 employees, so the user count is low, but the manpower can be moved around to many different machines.

With our MRP testing so far, we have used 2 MRP and 2 schedule processes. We can run a Net Change is just a few minutes. A Regen never seems to complete. Watching the logs, it will get stuck on a job and the log for that will basically grow forever...over 700Meg... before we canceled the process. Even then, the log continued to grow and did so until we reset the app servers. Strangely, we could go back and schedule the job manually and it would complete, so not sure if we are dealing with a BOM problem or not. I have contacted Epicor but haven't heard back yet.

--- In vantage@yahoogroups.com, "Tim Vonderhaar" <tvonderhaar@...> wrote:
>
> We are running some pilot MRP tests and are struggling a bit to understand if things are working as expected. We are reading through the MRP Tech Ref Guide, but would like to know what others have actually experienced in their organization. I understand that this isn't a one size fits all thing, but would like to get a few points of reference.
>
> 1) How long does MRP take to run, using a) Regenerative b) Net Change?
> 2) How often do you run Regenerative?
> 3) Do you use Finite Scheduling?
> 4) What number of MRP processes do you use?
> 5) What number of schedulers do you use?
> 6) Have you ever had the MRP process lock up? If so, how can one tell?
> 7) Do you use logging? If so, what setting do you use? a) basic b) MRP c) MRP and Scheduling?
> 8) Are your parts constrained?
> 9) Do you use APS?
> 10) Any lessons learned?
>
> Thanks,
> Tim
>





[Non-text portions of this message have been removed]
10
Does anyone know what to say to planners/purchase agents when
Vantage/E9 tells them to order more material than they need because
the lead time of a new order is less than an existing order? I'm used
to systems sending an expedite/delay message and not a new order and
then a subsequent cancel request. Suppliers seem more conducive to the
former. I'd love to hear how one could use any of the modifiers or APS
or whatever so our planners can trust the suggestions that MRP is
making. I've asked several Epicor people about this and they were
going to get back to us but I haven't heard anything in a couple of
years. Clearly others are getting the job done and I'm just curious
how.

Thanks!

Mark W.
11
I have found one part that the scheduler was looping on. Temporarily, I removed it's demand and re-ran. This time it got further, but it locked up again. No loop, just appeared to stop. No log activity, nor CPU usage. I then tried using 1 and 1 for the threads and it completed without issue. Unbelievable that this problem exists.

--- In vantage@yahoogroups.com, "Charles Carden" <shadowcar1449@...> wrote:
>
> Tom, good luck with support for MRP. I have never had any luck with them at all. They always say nothing is wrong, hmmm that is hard for me to believe. Try running only 1 MRP process and 1 Scheduling process. That should take care of the lock ups. We were getting the same results you are getting until we changed to 1 and 1. We never could determine the problem either.
>
> Charles Carden
> IT Manager
> Manitex, Inc.
> Georgetown, Texas
> ----- Original Message -----
> From: Tim Vonderhaar
> To: vantage@yahoogroups.com
> Sent: Monday, November 14, 2011 8:49 AM
> Subject: [Vantage] Re: MRP and scheduling
>
>
>
> Thanks everyone for the input.
>
> I have to say, I'm worried hearing about the temperamental nature of the MRP threads and things locking up. Such a fundamental part of an ERP system should be rock solid.
>
> Our environment is pretty rough. We have a very broad product line with some units still running after being in service for 30 years. Unlike many companies today, we seem to never to be able to obsolete a product.
>
> We have 45000 parts in our parts master with 24000 of them manufactured in house. 1/3 of our business is new, 1/3 is repair and 1/3 is spare parts. Our shop is mix of specialized and general purpose, very few are dedicated. We had to opt for the APS module to allow us to get around the single resource can only exist in a single resource group problem. We are small, only 45 employees, so the user count is low, but the manpower can be moved around to many different machines.
>
> With our MRP testing so far, we have used 2 MRP and 2 schedule processes. We can run a Net Change is just a few minutes. A Regen never seems to complete. Watching the logs, it will get stuck on a job and the log for that will basically grow forever...over 700Meg... before we canceled the process. Even then, the log continued to grow and did so until we reset the app servers. Strangely, we could go back and schedule the job manually and it would complete, so not sure if we are dealing with a BOM problem or not. I have contacted Epicor but haven't heard back yet.
>
> --- In vantage@yahoogroups.com, "Tim Vonderhaar" <tvonderhaar@> wrote:
> >
> > We are running some pilot MRP tests and are struggling a bit to understand if things are working as expected. We are reading through the MRP Tech Ref Guide, but would like to know what others have actually experienced in their organization. I understand that this isn't a one size fits all thing, but would like to get a few points of reference.
> >
> > 1) How long does MRP take to run, using a) Regenerative b) Net Change?
> > 2) How often do you run Regenerative?
> > 3) Do you use Finite Scheduling?
> > 4) What number of MRP processes do you use?
> > 5) What number of schedulers do you use?
> > 6) Have you ever had the MRP process lock up? If so, how can one tell?
> > 7) Do you use logging? If so, what setting do you use? a) basic b) MRP c) MRP and Scheduling?
> > 8) Are your parts constrained?
> > 9) Do you use APS?
> > 10) Any lessons learned?
> >
> > Thanks,
> > Tim
> >
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
12
I'm curious as to what the procedure problem was with the assemblies. As I have seen, we have one method that causes the scheduler to loop forever. Comparing it against one that doesn't have a problem, I'm not immediately seeing a difference. What exactly is your procedure and what do you do to fix a problematic method?

Tim

--- In vantage@yahoogroups.com, "Charles Carden" <shadowcar1449@...> wrote:
>
> We have been running MRP for about 6 years. We have had some bad experiences with it but most of that was caused by too little processing power. When we first started running MRP on a 32 bit Windows 2003 Standard with 4GB of memory it was taking 13 hours to run a REGEN and about 2 hours to run a Net Change. Because of time constraints we only ran REGEN on the weekend. At that time we had about 57,000 parts in the systems and a job backlog of 10-12 months. We ran MRP out 7 months to catch parts with 6 months lead time. Eventually with upgrades to Vantage our MRP processing time was cut down to about 8 hours for a REGEN. FYI, at that time were were building about 30 - 40 units a month with each unit having 11 levels of about 1700 parts. We were told this machine was good enough but soon found out it was not.
>
> We ran that way for about 2 years and then upgraded the server to 64bit Windows 2003 Standard with 32GB of memory with two dual core Xeon processors. A MRP REGEN went from 8 hours to a little under 2 hours. Knowing this I can say for sure that you do need to ensure you do not skimp on hardware or memory. A 64bit operating system is an absolute must. With that number of cores and processors MRP would take from 20% to 80% of the processing power of the machine. We have since upgraded the server to one with dual 6 core Xeons with hyper theading. That now gives 24 processors. MRP now only takes about 3% of processing power. One thing to note about a REGEN, the first thing it does is to delete all on the un-firmed jobs. During that deletion process the machine is unusable because of disk access and that is with 15k SCSI drives in a Raid 10 configuration. The new machine did not cut down on the MRP processing time but it did allow use of the machine during it runtime. We can now run a Net Change during the day without any disruption to the users. We are currently running version 8.03.408b but working on upgrading to Epicor 9.05.xxx by 2013.
>
> We do not do Finite scheduling nor are our parts constrained. We do not use APS. We run one MRP process and one scheduler. If we tried to run more that one of each MRP would lock up on us about 90% of the time. I have not tried using more in quite some time and it might work now but with the short time it takes MRP to run I don't see any use in running the risk. Even when MRP did not lock up when we were running more that one MRP process and/or schedulers I did not see that it saved a significant amount of time. That was probably caused because the machine did not have enough processing power. We use logging and it is set to MRP. The reason for this is to catch any errors that cause an assembly or unit to not be scheduled because of errors in the BOM (usually caused by an unapproved assembly). You only have to search the log for the word "assembly" to find any errors.
>
> We had MRP lock up on us a lot when we first started using it. We had to train our engineers to stop adding new assemblies, make it a component of a current BOM, make it effective immediately and leaving it unapproved. That combination would lock up MRP every time. Once the engineers changed their procedures we have not had MRP lockup on use but one time in the last two years. That lockup was caused by the combination above; we just had an engineer forget the proper procedure.
>
> You are right that one size does not fit all. We found very quickly that the operating system, number of processors and memory are key factors. The number of parts, the complexity of your BOM and the number of jobs to be scheduled will determine the amount of processing power you will need. Knowing what I know now I would budget the best machine that I could afford and then try to upgrade that to a better one when I actually make the purchase. Of course, you also have to keep in mind the number of users you have as well. My advice for that is to get a much memory as you can afford. Keep in mind that 64bit Windows Standard will only see 32GB of memory. My last two servers have had 32GB of memory although we typically never use more than are 13GB. It never hurts to have more than you need and with the low cost of memory today there is no use in skimping.
>
> If I made any sense to you then I hope I was some help. I am typing this with my wife and step-son right behind me talking about guitars and asking me questions.
>
>
> Charles Carden
> IT Manager
> Manitex, Inc.
> Georgetown, Texas
> ----- Original Message -----
> From: Tim Vonderhaar
> To: vantage@yahoogroups.com
> Sent: Friday, November 11, 2011 12:10 PM
> Subject: [Vantage] MRP and scheduling
>
>
>
> We are running some pilot MRP tests and are struggling a bit to understand if things are working as expected. We are reading through the MRP Tech Ref Guide, but would like to know what others have actually experienced in their organization. I understand that this isn't a one size fits all thing, but would like to get a few points of reference.
>
> 1) How long does MRP take to run, using a) Regenerative b) Net Change?
> 2) How often do you run Regenerative?
> 3) Do you use Finite Scheduling?
> 4) What number of MRP processes do you use?
> 5) What number of schedulers do you use?
> 6) Have you ever had the MRP process lock up? If so, how can one tell?
> 7) Do you use logging? If so, what setting do you use? a) basic b) MRP c) MRP and Scheduling?
> 8) Are your parts constrained?
> 9) Do you use APS?
> 10) Any lessons learned?
>
> Thanks,
> Tim
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
13
Here's my 2 cents on MRP:



1) How long does MRP take to run, using a) Regenerative b) Net Change?
We only run regenerative and it takes about an hour and a half
> 2) How often do you run Regenerative? Nightly M - F and early Sunday
morning
> 3) Do you use Finite Scheduling? no
> 4) What number of MRP processes do you use? 2
> 5) What number of schedulers do you use? 2
> 6) Have you ever had the MRP process lock up? If so, how can one tell?
Yes, due to the appserver locking up. We have pinpointed this to our backup
process. We are running a SQL database.
> 7) Do you use logging? If so, what setting do you use? a) basic b) MRP c)
MRP and Scheduling? Basic, unless I'm troubleshooting something.
> 8) Are your parts constrained? No, we ignore constrained materials.
> 9) Do you use APS?
> 10) Any lessons learned? We do run the multi-level pegging process and we
have approx. 55,000 parts. We are on version 9.04.507A.





Beth Rye

IT Director

CIGNYS
Email: <mailto:brye@...> brye@...



***ITAR NOTICE***

This e-mail and/or the attached documents may contain technical data within
the definition of the International Traffic in Arms regulations, and are
subject to the export control laws of the US Government. Transfer of this
data by any means to a foreign person, whether in the US or abroad, without
an export license or other approval from the US Department of State, is
prohibited. No portion of this e-mail or its attachment(s) may be reproduced
without written consent of CIGNYS. If you are not the intended recipient or
believe that you may have received this document in error, please notify the
sender and delete this e-mail and any attachments immediately.



> ----- Original Message -----
> From: Tim Vonderhaar
> To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> Sent: Friday, November 11, 2011 12:10 PM
> Subject: [Vantage] MRP and scheduling
>
>
>
> We are running some pilot MRP tests and are struggling a bit to understand
if things are working as expected. We are reading through the MRP Tech Ref
Guide, but would like to know what others have actually experienced in their
organization. I understand that this isn't a one size fits all thing, but
would like to get a few points of reference.
>
> 1) How long does MRP take to run, using a) Regenerative b) Net Change?
> 2) How often do you run Regenerative?
> 3) Do you use Finite Scheduling?
> 4) What number of MRP processes do you use?
> 5) What number of schedulers do you use?
> 6) Have you ever had the MRP process lock up? If so, how can one tell?
> 7) Do you use logging? If so, what setting do you use? a) basic b) MRP c)
MRP and Scheduling?
> 8) Are your parts constrained?
> 9) Do you use APS?
> 10) Any lessons learned?
>
> Thanks,
> Tim
>
>
>
>
>
> [Non-text portions of this message have been removed]
>





[Non-text portions of this message have been removed]
14
We have taken your advice and this approach appears to work much better. We did find one additional problem that I wanted to check and see what others may know.

We have manufactured parts that we may outsource. If the part is marked as manufactured, but has a lead time other than zero, this seems to cause looping problems with the scheduler as well. I realize that having a lead time for a manufactured part is odd, but we figured it was better to have the number kept somewhere and figured Epicor would ignore it when a part is set as manufactured.

--- In vantage@yahoogroups.com, Sirow Richard <rick@...> wrote:
>
> Tom,
>
> We have also had the problem of MRP looping. A suggestion that another user made was to uncheck the Run Finite Scheduling during MPR calculation. We then run Calculate Global Scheduling Order, then Global Scheduling. Since we made that change, we have not had a looping issue.
>
> Richard L. Sirow, President
> www.iccparts.com
> rick@...
>
> On Nov 14, 2011, at 9:49 AM, Tim Vonderhaar wrote:
>
> > Thanks everyone for the input.
> >
> > I have to say, I'm worried hearing about the temperamental nature of the MRP threads and things locking up. Such a fundamental part of an ERP system should be rock solid.
> >
> > Our environment is pretty rough. We have a very broad product line with some units still running after being in service for 30 years. Unlike many companies today, we seem to never to be able to obsolete a product.
> >
> > We have 45000 parts in our parts master with 24000 of them manufactured in house. 1/3 of our business is new, 1/3 is repair and 1/3 is spare parts. Our shop is mix of specialized and general purpose, very few are dedicated. We had to opt for the APS module to allow us to get around the single resource can only exist in a single resource group problem. We are small, only 45 employees, so the user count is low, but the manpower can be moved around to many different machines.
> >
> > With our MRP testing so far, we have used 2 MRP and 2 schedule processes. We can run a Net Change is just a few minutes. A Regen never seems to complete. Watching the logs, it will get stuck on a job and the log for that will basically grow forever...over 700Meg... before we canceled the process. Even then, the log continued to grow and did so until we reset the app servers. Strangely, we could go back and schedule the job manually and it would complete, so not sure if we are dealing with a BOM problem or not. I have contacted Epicor but haven't heard back yet.
> >
> > --- In vantage@yahoogroups.com, "Tim Vonderhaar" <tvonderhaar@> wrote:
> > >
> > > We are running some pilot MRP tests and are struggling a bit to understand if things are working as expected. We are reading through the MRP Tech Ref Guide, but would like to know what others have actually experienced in their organization. I understand that this isn't a one size fits all thing, but would like to get a few points of reference.
> > >
> > > 1) How long does MRP take to run, using a) Regenerative b) Net Change?
> > > 2) How often do you run Regenerative?
> > > 3) Do you use Finite Scheduling?
> > > 4) What number of MRP processes do you use?
> > > 5) What number of schedulers do you use?
> > > 6) Have you ever had the MRP process lock up? If so, how can one tell?
> > > 7) Do you use logging? If so, what setting do you use? a) basic b) MRP c) MRP and Scheduling?
> > > 8) Are your parts constrained?
> > > 9) Do you use APS?
> > > 10) Any lessons learned?
> > >
> > > Thanks,
> > > Tim
> > >
> >
> >
>
>
>
> [Non-text portions of this message have been removed]
>
15
We had a problem getting MRP to complete over the summer and after WAY
TOO much of a hassle, we finally found the right tech support person to
help us. The problem was in regards to table level indexes not being set
correctly. We used a Trace Profile within SQL to identify the culprit
tables and made those fixes per the tech support rep. Basically, every
time MRP came upon a deadlock issue in the database, it would result in
an hour delay of MRP. We have not gone live yet, but in all of our
tests, MRP has only taken minutes to run on a smaller population of
parts that we will be running it against once we are live. My current
ERP system only takes about 30 minutes to run, but it does not tie into
the scheduling system. It only uses the leadtime we populate in the
system for rough planning. In Epicor, I have used the MRP and Schedule
method, and have been happy with it once we tweaked the indexes.
Unfortunately, I do not have good notes on what we did, so I would
recommend forcing this issue with Epicor Tech Support. I think the
support agent was named Matt. We went through half a dozen people before
coming into contact with him though. It sounded to me like a SQL script
had not been run during install.....or that there should be created for
that purpose. MRP is a HUGE part of any ERP system, and it should work
out of the box. Hope this helps. (E9 905.607a, but all testing was done
on 905.604 to date. We will test 905.607 in January)

Thank you!

Jason Dearth
Director of Production Control
Ferco Tech Corporation
jdearth@...
937-746-6696 x 180

-----Original Message-----
From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of Sirow Richard
Sent: Monday, November 14, 2011 10:38 AM
To: vantage@yahoogroups.com
Subject: Re: [Vantage] MRP and scheduling

Tom,

We have also had the problem of MRP looping. A suggestion that another
user made was to uncheck the Run Finite Scheduling during MPR
calculation. We then run Calculate Global Scheduling Order, then Global
Scheduling. Since we made that change, we have not had a looping issue.

Richard L. Sirow, President
www.iccparts.com
rick@...

On Nov 14, 2011, at 9:49 AM, Tim Vonderhaar wrote:

> Thanks everyone for the input.
>
> I have to say, I'm worried hearing about the temperamental nature of
the MRP threads and things locking up. Such a fundamental part of an ERP
system should be rock solid.
>
> Our environment is pretty rough. We have a very broad product line
with some units still running after being in service for 30 years.
Unlike many companies today, we seem to never to be able to obsolete a
product.
>
> We have 45000 parts in our parts master with 24000 of them
manufactured in house. 1/3 of our business is new, 1/3 is repair and 1/3
is spare parts. Our shop is mix of specialized and general purpose, very
few are dedicated. We had to opt for the APS module to allow us to get
around the single resource can only exist in a single resource group
problem. We are small, only 45 employees, so the user count is low, but
the manpower can be moved around to many different machines.
>
> With our MRP testing so far, we have used 2 MRP and 2 schedule
processes. We can run a Net Change is just a few minutes. A Regen never
seems to complete. Watching the logs, it will get stuck on a job and the
log for that will basically grow forever...over 700Meg... before we
canceled the process. Even then, the log continued to grow and did so
until we reset the app servers. Strangely, we could go back and schedule
the job manually and it would complete, so not sure if we are dealing
with a BOM problem or not. I have contacted Epicor but haven't heard
back yet.
>
> --- In vantage@yahoogroups.com, "Tim Vonderhaar" <tvonderhaar@...>
wrote:
> >
> > We are running some pilot MRP tests and are struggling a bit to
understand if things are working as expected. We are reading through the
MRP Tech Ref Guide, but would like to know what others have actually
experienced in their organization. I understand that this isn't a one
size fits all thing, but would like to get a few points of reference.
> >
> > 1) How long does MRP take to run, using a) Regenerative b) Net
Change?
> > 2) How often do you run Regenerative?
> > 3) Do you use Finite Scheduling?
> > 4) What number of MRP processes do you use?
> > 5) What number of schedulers do you use?
> > 6) Have you ever had the MRP process lock up? If so, how can one
tell?
> > 7) Do you use logging? If so, what setting do you use? a) basic b)
MRP c) MRP and Scheduling?
> > 8) Are your parts constrained?
> > 9) Do you use APS?
> > 10) Any lessons learned?
> >
> > Thanks,
> > Tim
> >
>
>



[Non-text portions of this message have been removed]



------------------------------------

Useful links for the Yahoo!Groups Vantage Board are: ( Note: You must
have already linked your email address to a yahoo id to enable access. )
(1) To access the Files Section of our Yahoo!Group for Report Builder
and Crystal Reports and other 'goodies', please goto:
http://groups.yahoo.com/group/vantage/files/.
(2) To search through old msg's goto:
http://groups.yahoo.com/group/vantage/messages
(3) To view links to Vendors that provide Vantage services goto:
http://groups.yahoo.com/group/vantage/linksYahoo! Groups Links
16
Sadly, that seems to be the case more and more. The right tech person takes ownership of a problem and works to see it get fixed. Others just want to clear their work queue, not matter the outcome.

Thanks for the input.

--- In vantage@yahoogroups.com, "Jason Dearth" <jdearth@...> wrote:
>
> We had a problem getting MRP to complete over the summer and after WAY
> TOO much of a hassle, we finally found the right tech support person to
> help us. The problem was in regards to table level indexes not being set
> correctly. We used a Trace Profile within SQL to identify the culprit
> tables and made those fixes per the tech support rep. Basically, every
> time MRP came upon a deadlock issue in the database, it would result in
> an hour delay of MRP. We have not gone live yet, but in all of our
> tests, MRP has only taken minutes to run on a smaller population of
> parts that we will be running it against once we are live. My current
> ERP system only takes about 30 minutes to run, but it does not tie into
> the scheduling system. It only uses the leadtime we populate in the
> system for rough planning. In Epicor, I have used the MRP and Schedule
> method, and have been happy with it once we tweaked the indexes.
> Unfortunately, I do not have good notes on what we did, so I would
> recommend forcing this issue with Epicor Tech Support. I think the
> support agent was named Matt. We went through half a dozen people before
> coming into contact with him though. It sounded to me like a SQL script
> had not been run during install.....or that there should be created for
> that purpose. MRP is a HUGE part of any ERP system, and it should work
> out of the box. Hope this helps. (E9 905.607a, but all testing was done
> on 905.604 to date. We will test 905.607 in January)
>
> Thank you!
>
> Jason Dearth
> Director of Production Control
> Ferco Tech Corporation
> jdearth@...
> 937-746-6696 x 180
>
> -----Original Message-----
> From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
> Of Sirow Richard
> Sent: Monday, November 14, 2011 10:38 AM
> To: vantage@yahoogroups.com
> Subject: Re: [Vantage] MRP and scheduling
>
> Tom,
>
> We have also had the problem of MRP looping. A suggestion that another
> user made was to uncheck the Run Finite Scheduling during MPR
> calculation. We then run Calculate Global Scheduling Order, then Global
> Scheduling. Since we made that change, we have not had a looping issue.
>
> Richard L. Sirow, President
> www.iccparts.com
> rick@...
>
> On Nov 14, 2011, at 9:49 AM, Tim Vonderhaar wrote:
>
> > Thanks everyone for the input.
> >
> > I have to say, I'm worried hearing about the temperamental nature of
> the MRP threads and things locking up. Such a fundamental part of an ERP
> system should be rock solid.
> >
> > Our environment is pretty rough. We have a very broad product line
> with some units still running after being in service for 30 years.
> Unlike many companies today, we seem to never to be able to obsolete a
> product.
> >
> > We have 45000 parts in our parts master with 24000 of them
> manufactured in house. 1/3 of our business is new, 1/3 is repair and 1/3
> is spare parts. Our shop is mix of specialized and general purpose, very
> few are dedicated. We had to opt for the APS module to allow us to get
> around the single resource can only exist in a single resource group
> problem. We are small, only 45 employees, so the user count is low, but
> the manpower can be moved around to many different machines.
> >
> > With our MRP testing so far, we have used 2 MRP and 2 schedule
> processes. We can run a Net Change is just a few minutes. A Regen never
> seems to complete. Watching the logs, it will get stuck on a job and the
> log for that will basically grow forever...over 700Meg... before we
> canceled the process. Even then, the log continued to grow and did so
> until we reset the app servers. Strangely, we could go back and schedule
> the job manually and it would complete, so not sure if we are dealing
> with a BOM problem or not. I have contacted Epicor but haven't heard
> back yet.
> >
> > --- In vantage@yahoogroups.com, "Tim Vonderhaar" <tvonderhaar@>
> wrote:
> > >
> > > We are running some pilot MRP tests and are struggling a bit to
> understand if things are working as expected. We are reading through the
> MRP Tech Ref Guide, but would like to know what others have actually
> experienced in their organization. I understand that this isn't a one
> size fits all thing, but would like to get a few points of reference.
> > >
> > > 1) How long does MRP take to run, using a) Regenerative b) Net
> Change?
> > > 2) How often do you run Regenerative?
> > > 3) Do you use Finite Scheduling?
> > > 4) What number of MRP processes do you use?
> > > 5) What number of schedulers do you use?
> > > 6) Have you ever had the MRP process lock up? If so, how can one
> tell?
> > > 7) Do you use logging? If so, what setting do you use? a) basic b)
> MRP c) MRP and Scheduling?
> > > 8) Are your parts constrained?
> > > 9) Do you use APS?
> > > 10) Any lessons learned?
> > >
> > > Thanks,
> > > Tim
> > >
> >
> >
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Useful links for the Yahoo!Groups Vantage Board are: ( Note: You must
> have already linked your email address to a yahoo id to enable access. )
> (1) To access the Files Section of our Yahoo!Group for Report Builder
> and Crystal Reports and other 'goodies', please goto:
> http://groups.yahoo.com/group/vantage/files/.
> (2) To search through old msg's goto:
> http://groups.yahoo.com/group/vantage/messages
> (3) To view links to Vendors that provide Vantage services goto:
> http://groups.yahoo.com/group/vantage/linksYahoo! Groups Links
>
17
1. How long does MRP take to run, using a) Regenerative b) Net Change?
Never use net change, always regen. Its run Mon to Thurs early morning. It takes about 30 mins to run. We have about 6000 parts on the system and BOMs are generally no more than 5 or 6 levels.

3. Yes we use finite scheduling

4. 1 process for MRP and 1 scheduler

5. We do occasionally get lock ups. As part of the daily tasks we check the appserver for stuck processes, deleting those usually clears things.

7. We log MRP and schedule activity

8. Parts are constrained.

Any other issues ? Is anyone aware of a third party scheduling tool which interfaces with Vantage (we run 8.03.408) ?
Our experience with MRP is mixed to say the least. Initially it produced vast volumes of spurious suggestions which with the help of an outside consultant we eventually managed to resolve, however it still leaves us scratching our heads at times.
Do people in this forum use the scheduling boards ? Or do you have something else that can be used to manipulate data in a similar sort of graphical way ?

Thanks

Bill





--- In vantage@yahoogroups.com, "Tim Vonderhaar" <tvonderhaar@...> wrote:
>
> We are running some pilot MRP tests and are struggling a bit to understand if things are working as expected. We are reading through the MRP Tech Ref Guide, but would like to know what others have actually experienced in their organization. I understand that this isn't a one size fits all thing, but would like to get a few points of reference.
>
> 1) How long does MRP take to run, using a) Regenerative b) Net Change?
> 2) How often do you run Regenerative?
> 3) Do you use Finite Scheduling?
> 4) What number of MRP processes do you use?
> 5) What number of schedulers do you use?
> 6) Have you ever had the MRP process lock up? If so, how can one tell?
> 7) Do you use logging? If so, what setting do you use? a) basic b) MRP c) MRP and Scheduling?
> 8) Are your parts constrained?
> 9) Do you use APS?
> 10) Any lessons learned?
>
> Thanks,
> Tim
>