I guess it depends upon what portion of the system your business critically relies upon.
In our case, scheduling & materials management are key & the 404 the scheduler was completely broken (forward scheduled jobs being scheduled backwards and vice-versa, wrong job date used to calculate scheduling order, scheduling priority multiplier not used in schedule order calc at all... I could go on). Material planning was also a nightmare due to an acknowledged bug that generated partial 'extra' JobAssy records that totally screwed up allocations and, we believe, made MRP behave erratically as we found PartDtl records to be quite inaccurate and incomplete.
All have been fixed in 405a. Other bugs still exist (dating back nearly 2 years at this point for many) but we have customizations, BPMs & BAMs that reliably negate them.
We don't use now (or likely ever will use) BookDtls. If you say it was broken between 404d & 405a, my sympathies.
We no longer trust the quality of Epicor's release process at all and will never blindly apply a new release without rigid pretesting. We spent weeks setting up a valid test environment for 405a & testing it.
I would urge all to do the same.
Rob Brown
In our case, scheduling & materials management are key & the 404 the scheduler was completely broken (forward scheduled jobs being scheduled backwards and vice-versa, wrong job date used to calculate scheduling order, scheduling priority multiplier not used in schedule order calc at all... I could go on). Material planning was also a nightmare due to an acknowledged bug that generated partial 'extra' JobAssy records that totally screwed up allocations and, we believe, made MRP behave erratically as we found PartDtl records to be quite inaccurate and incomplete.
All have been fixed in 405a. Other bugs still exist (dating back nearly 2 years at this point for many) but we have customizations, BPMs & BAMs that reliably negate them.
We don't use now (or likely ever will use) BookDtls. If you say it was broken between 404d & 405a, my sympathies.
We no longer trust the quality of Epicor's release process at all and will never blindly apply a new release without rigid pretesting. We spent weeks setting up a valid test environment for 405a & testing it.
I would urge all to do the same.
Rob Brown
--- On Wed, 8/27/08, Jeff Stockard <jeff.stockard@...> wrote:
From: Jeff Stockard <jeff.stockard@...>
Subject: RE: [Vantage] How do you determine which Vantage patch level to upgrade to?
To: vantage@yahoogroups.com
Date: Wednesday, August 27, 2008, 3:59 PM
Was that the release with the 3 digit year problem? That was the first time
I heard of a Y1K computer problem.
We are on 803.405 we have several problems that they tell us are fixed in
803.405a. We cannot move to any other level of update until they fix the
issue with the Book details creating thousands of records. We use that
table to get our Sales data. We use the same Sales orders and add releases
when the customer needs more. The BookDtls table is the only one that keeps
a date for releases. If they had a working date field in the OrderDtl
table, I would be all set, but the programming is not there. I would
definitely NOT move to 803.405.
We tested in 803.404d and all of the things we do worked. 803.405 came out
a few days before we migrated from 803.305 and they upgraded our database to
803.405 and it has been a nightmare.
From: vantage@yahoogroups .com [mailto:vantage@yahoogroups .com] On Behalf Of
Robert Brown
Sent: Wednesday, August 27, 2008 3:34 PM
To: vantage@yahoogroups .com
Subject: Re: [Vantage] How do you determine which Vantage patch level to
upgrade to?
Any reason you are not going all the way to 405A?
(404 in general was buggy as heck. I hope to never see another release
'released' of such poor quality.)
--- On Wed, 8/27/08, jmpratt7 <james.pratt@ ameridrives. com
<mailto:james. pratt%40ameridri ves.com> > wrote:
From: jmpratt7 <james.pratt@ ameridrives. com
<mailto:james. pratt%40ameridri ves.com> >
Subject: [Vantage] How do you determine which Vantage patch level to upgrade
to?
To: vantage@yahoogroups .com <mailto:vantage% 40yahoogroups. com>
Date: Wednesday, August 27, 2008, 3:17 PM
We are currently on 8.00.811B and are planning to upgrade to 8.03.404A
in the near future. As part of this process I am reviewing the patch
guides for releases greater than 8.03.404A to help determine what
issues we may expect to encounter at 8.03.404A (based on what gets
fixed in later releases). This is in addition to normal testing,
including a mock upgrade and comparison of data and reports before and
after.
Does anybody have a process better than what I've described. When
talking with the support group, they always recommend that we go for
the latest patch, but since there is no user or support data to
reference, this can be a costly way to go in terms of testing and
problem resolution time.
Appreciate your thoughts on this issue.
Jim Pratt
[Non-text portions of this message have been removed]