803 (305 & 404) are client & server resource hogs. 404 improved the situation is some areas but it seems to be worse in others. Likely most issues are nothing some server & network tuning can't resolve but I've read on this group that some are suffering server memory leak issues (although we haven't experienced this - ?yet?).
They also introduced some table changes (unadvertised) between 305 & 404 which broke some of our legacy system data import routines, a few reports, and some customizations.
To their credit, quite a few 'high impact' bugs have been fixed between 305 and 404 (for which 404A was just released but we haven't installed yet).
Areas with problems are:
MES (a problem with End Activity reporting - something pretty serious, a few annoying performance issues with 'select for work' subprocesses, etc.,).
Global Rescheduler - This was broken up into 3 apps (a recurring schedulable "Calculate Global Scheduling Order" app, the option for a manual intervention "Adjust Global Scheduling Order" app - not likely to be used for a company like us that runs MRP and scheduling at night, and the recurring schedulable "Global Scheduler" itself).
Splitting up the Global like this revealed a MAJOR bug (which clearly existed prior to the app split) - The scheduling sequence priority logic is using the wrong date when calculating scheduling sequence.
It is calculating 'days late' to the prior day's as-scheduled Due Dates (which they deceptively labeled as "Req Due Date" in the apps & app epidataview) instead of the Actual Job Req'd By Dates. This results in schedule 'churning' (you can run the global 10 times in a row with no labor activity occurring between each run and you will get 10 different schedules - each worse than the previous in regard to actual fulfilling actual requirement fulfillment needs).
Any one else suffering from this (which should only impact you if you finite schedule as we do) can attach themselves to 1065776PSC and perhaps it'll get fixed sooner than later.
Other than than, nothing of note that wasn't screwed up before.
We started on 305 so I can't offer any comparison 810/812.
Hope that helps.
Rob Brown
John Holden <jholden@...> wrote:
The word is from Vantage is that they indeed were able to duplicate
it however they are not going to attempt a fix in 8.0 as they have
left it and all its bugs behind to focus on the .803 version. I
really wasn't ready to move to .803 but it seems as if I am going to
have to. It sounds like from talking to others that I will have to
recreate every crystal report I use, buy a new server and bring in an
IT crew to get that setup then begin looking for bugs in that
version. Tell me, what does .803 look like these days? I hesitate
to go there because of all the problems I saw when they brought it
out.
--- In vantage@yahoogroups.com, Robert Brown <robertb_versa@...>
wrote:
occurs.
Never miss a thing. Make Yahoo your homepage.
[Non-text portions of this message have been removed]
They also introduced some table changes (unadvertised) between 305 & 404 which broke some of our legacy system data import routines, a few reports, and some customizations.
To their credit, quite a few 'high impact' bugs have been fixed between 305 and 404 (for which 404A was just released but we haven't installed yet).
Areas with problems are:
MES (a problem with End Activity reporting - something pretty serious, a few annoying performance issues with 'select for work' subprocesses, etc.,).
Global Rescheduler - This was broken up into 3 apps (a recurring schedulable "Calculate Global Scheduling Order" app, the option for a manual intervention "Adjust Global Scheduling Order" app - not likely to be used for a company like us that runs MRP and scheduling at night, and the recurring schedulable "Global Scheduler" itself).
Splitting up the Global like this revealed a MAJOR bug (which clearly existed prior to the app split) - The scheduling sequence priority logic is using the wrong date when calculating scheduling sequence.
It is calculating 'days late' to the prior day's as-scheduled Due Dates (which they deceptively labeled as "Req Due Date" in the apps & app epidataview) instead of the Actual Job Req'd By Dates. This results in schedule 'churning' (you can run the global 10 times in a row with no labor activity occurring between each run and you will get 10 different schedules - each worse than the previous in regard to actual fulfilling actual requirement fulfillment needs).
Any one else suffering from this (which should only impact you if you finite schedule as we do) can attach themselves to 1065776PSC and perhaps it'll get fixed sooner than later.
Other than than, nothing of note that wasn't screwed up before.
We started on 305 so I can't offer any comparison 810/812.
Hope that helps.
Rob Brown
John Holden <jholden@...> wrote:
The word is from Vantage is that they indeed were able to duplicate
it however they are not going to attempt a fix in 8.0 as they have
left it and all its bugs behind to focus on the .803 version. I
really wasn't ready to move to .803 but it seems as if I am going to
have to. It sounds like from talking to others that I will have to
recreate every crystal report I use, buy a new server and bring in an
IT crew to get that setup then begin looking for bugs in that
version. Tell me, what does .803 look like these days? I hesitate
to go there because of all the problems I saw when they brought it
out.
--- In vantage@yahoogroups.com, Robert Brown <robertb_versa@...>
wrote:
>what you describe in this release.
> We are pilot testing 8.03.404 right now and they seem to have fixed
>(before actually entering anything)?
> What happens if you do a refresh after starting a new line
>customization that triggers a refresh when a new line record event
> If that by chance clears up the problem, you could try to add a
occurs.
>fix it?)
> ...No help from Epicor? (No specific 812 code patch available to
>IUM have
> Wish I could be of more help.
>
> Rob Brown
>
> John Holden <jholden@...> wrote:
> Thanks for the comment Robert but the fact is the PUM and
> been set up correctly in the Part master. The problem is that thethe
> Purchase Entry has a mind of its own and whatever defaults in there
> is what you are usually stuck with. I have heard that the default
> price, factor and UofM defaults into a new PO based off of the
> previous settings for this part. This seemed to make sense for over
> two years but only since I UPGRADED from 810B to 812 did I notice
> inability to changed the PO defaults. Also, to add to your comment,add.
> I suppose there may be some instances where due to a supplier
> limitation or some other factor, you should be able to change the
> factor/UofM, etc. Let's say one vendor uses lbs of steel tubing
> while another uses feet. Please respond back if you have more to
>IUM
> Thanks, John
>
> --- In vantage@yahoogroups.com, Robert Brown <robertb_versa@>
> wrote:
> >
> > Why would your PUM to IUM conversion factor vary? (Why not set it
> up correctly once in Part Maintenance?)
> >
> > Are you buying dimensional inventory? (ex: PUM = pounds for
> cut/sheared hot rolled plate of varying width x length dimensions
> using a generic part number for the plate-material/thickness - so
> of 'each' might require a different UM conversion rate for eachbuy).
> >not
> > ????
> >
> > Rob Brown
> >
> >
> >
> > John Holden <jholden@> wrote:
> > I am on 8.00.812 and have noticed an issue in the
> Purchase Entry screen
> > where some inventory parts allow me to change the IUM and PUM of
> the
> > Line Tab (PODetail.IUM & PODetail.PUM) however other parts will
> > allow me to Approve the PO and save the changes to the Line IUM ¬
> PUM
> > at all. It is very frustrating because when I create PO's for
> steel,
> > the wrong PUM or IUM is defaulting into these fields, yet will
> evendulpicate
> > allow me to save manual corrections. It looks like I am buying
> 45,000
> > each when really I am buying 45,000 lbs - (which if anyone could
> let
> > Vantage developers know makes a HUGE diff in inventory). I have
> > brought the issue to Vantage people and they were able to
> thework
> > issue however they will not be attempting a fix - please upgrade
> > to .803. I don't want to upgrade to .803 - I want the .812 to
> > correctly. Has anyone figured out how to correct/work around thisSearch.
> > issue? How do the many other companies out there keep inventory
> > straight with garbage PO's that confuse everyone?
> >
> >
>
>
>
>
>
>
> ---------------------------------
> Looking for last minute shopping deals? Find them fast with Yahoo!
>---------------------------------
> [Non-text portions of this message have been removed]
>
Never miss a thing. Make Yahoo your homepage.
[Non-text portions of this message have been removed]