On any given day (we run global nightly) about 30% of our finite resource scheduled jobs have OPs scheduled out of sequence (completely disrespecting the Finish-to-Start relationship of our OPs).
I'm not talking a 'little' off: Example: Job 123 has OP5 scheduled to start in mid March. OP10 will be scheduled to start IMMEDIATELY (today).
If materials are associated with these out-of sequence scheduled OPs it plays hell with material planning.
406 didn't fix it (and broke other things so we chose not to upgrade). 407 release notes hint that the problem is acknowledged. We'll be testing that this month.
Support has been useless. After MONTHs of back and forth (and even with a copy of our db) they have yet to acknowledge the problem. My last contact with them (2 weeks ago) I had then dump the JobHed, JobOper & JobOpDtl tables to csv and I pulled them into excel and SHOWED them the massively mischeduled OPs. After getting a "I'll call you tomorrow" response, I'm still awaiting the call back.
On Monday I start the escalation process. If they don't have support ON-SITE within a week (we are 15 minutes from their Parsippany NJ hub), I'll be recommending we dump support for the current year and file suit to recover last year's fees.
This product is not giving us a competitive edge over our competition. It is an OBSTACLE.
The 404 bugs (which we alerted them to and they fixed in 405) were with the Calculate Global Scheduling Order application. They were using the wrong date in the calculation (due date instead of required date) and also weren't using the scheduling code multiplier.
This COULD be an OK product if they didn't treat their customers like an enemy to be sucked dry via support fees (with no support in return for those fees).
I'll be surprised if they survive this recession.
Rob
I'm not talking a 'little' off: Example: Job 123 has OP5 scheduled to start in mid March. OP10 will be scheduled to start IMMEDIATELY (today).
If materials are associated with these out-of sequence scheduled OPs it plays hell with material planning.
406 didn't fix it (and broke other things so we chose not to upgrade). 407 release notes hint that the problem is acknowledged. We'll be testing that this month.
Support has been useless. After MONTHs of back and forth (and even with a copy of our db) they have yet to acknowledge the problem. My last contact with them (2 weeks ago) I had then dump the JobHed, JobOper & JobOpDtl tables to csv and I pulled them into excel and SHOWED them the massively mischeduled OPs. After getting a "I'll call you tomorrow" response, I'm still awaiting the call back.
On Monday I start the escalation process. If they don't have support ON-SITE within a week (we are 15 minutes from their Parsippany NJ hub), I'll be recommending we dump support for the current year and file suit to recover last year's fees.
This product is not giving us a competitive edge over our competition. It is an OBSTACLE.
The 404 bugs (which we alerted them to and they fixed in 405) were with the Calculate Global Scheduling Order application. They were using the wrong date in the calculation (due date instead of required date) and also weren't using the scheduling code multiplier.
This COULD be an OK product if they didn't treat their customers like an enemy to be sucked dry via support fees (with no support in return for those fees).
I'll be surprised if they survive this recession.
Rob
--- On Fri, 1/2/09, melissa hietala <kevmel822@...> wrote:
From: melissa hietala <kevmel822@...>
Subject: Re: [Vantage] Re: 407 ETA
To: vantage@yahoogroups.com
Date: Friday, January 2, 2009, 11:19 AM
What is the global scheduling bug you are referring to here? We have just started using at and have a few issues.
Thanks
 Melissa Hietala
UMC, Inc.
melissah@ultramc. com
____________ _________ _________ __
From: Robert Brown <robertb_versa@ yahoo.com>
To: vantage@yahoogroups .com
Sent: Thursday, December 18, 2008 7:20:15 AM
Subject: Re: [Vantage] Re: 407 ETA
Vic,
Clive is right (in our experience). 404 was an abomination (re bugs). 405(a) is much better (although still one HUGE bug with global scheduling - that 406 doesn't fix as we've tested).
I'd consider 405. If you're customized, the only area we found it broke customizations (404 to 405) was with PO Entry. Most of our customization in PO Entry to were self-fix bugs and they actually fixed many of the bugs (and cclearly made some major under the hood changes) so our 404 PO Entry customizations broke.
Other than that, the only thing close to being an OK (quality) release I've seen out of Epicor.
We don't feel compelled to blindly upgrade either. (More trouble than it's worth with Epicor's horrific release quality track record.)
I'm with you... I'll wait for v10 before seriously considering v9 & let others more daring do Epicor's QC for them. ....They should pay US! :)
We're in business to serve our customers & try to eke out a profit - Not just blindly play with the latest/greatest claimed Epicor offering & devote hundreds of hours to doing there QC for them.
Rob
--- On Thu, 12/18/08, clive.1972 <clive.1972@ yahoo. com> wrote:
From: clive.1972 <clive.1972@ yahoo. com>
Subject: [Vantage] Re: 407 ETA
To: vantage@yahoogroups .com
Date: Thursday, December 18, 2008, 3:21 AM
Vic,
I can remember at least three big bugs that were fixed in 405, you may
want to check the change list for 405 to see what bugs you're still
running with.
There's one fixed that can effect costs on materials issued to jobs and
another that sorts out a problem with change logs.
--- In vantage@yahoogroups .com, "Vic Drecchio" <vic.drecchio@ ...> wrote:
>
> I'm on 404B and staying. Why? It works.
>
> I've NEVER been a big fan of upgrading "just because" someone decides
to release a service pack.
>
> To this day I disable Windows Update on everything I own.
>
> "If it ain't broke, don't fix it."
>
> I learn the nuances and work-arounds on my version and stick with
it. Because every time an "upgrade" or "patch" is applied, 10 other
unknown new problems are revealed.
>
> I'm with Jonathan.... .. but I'll wait for Vantage 10. :-)
>
[Non-text portions of this message have been removed]