--- Vantage v5 bug list ---
-------------------
Date unknown 666102 - OPEN
APS Setup time field missing from part methods
-------------------
Date unknown 654346 - OPEN
W2 has incorrect wage info.
Hi Joe,
Development is working on this issue. I will keep you posted. Thanks,
Linda
-------------------
1-30-01 658757 - OPEN
Labor hours are wrong if shift passes midnight.
2-12-01 669499 - OPEN
Must turn off all shop warnings to make data collection work.
Patch 310 is supposed to fix this per Wendy at tech support.
We are testing as of 8:20am on 2-23-01.
v5 patch 310 does not fix the data collection bug about
shop warnings crashing data collection terminals.
I installed patch 310 on 2-23-01 at 3PM EST. At
9AM EST on 2-24-01 I turned shop warnings back on
in the company config. At 9:25am EST data collection
terminals started crashing with error messages stating
"Shopwrn in use by xxx". CPU utilization went to 100%
on both processors of a dual PIII 500Mhz terminal server
with 1G ram. Affected terminals had to be restarted.
Shop warnings had to be turned back off to make our system
operational again.
2/26/01 Matt Christus advised that server running the vantage
db needs to be rebooted for the patch to take effect. Will
test this theory asap.
2/27/01 Problem persists. Rebooting the server had no
effect.
3-8-01 Patch 312 supposedly fixes this but I have not tested it yet.
3-9-01 Tested - Still crashes
3-9-01 Sent Wendy export of shopwrn table.
-------------------
2-14-01 666086 - OPEN - SCR 1690
Entering a prefix in UNFIRM in comp config doesn't allow MRP to run.
If you don't enter a prefix MRP will run. In either case the
job number is 14 digits long.
MRP crashes when job number already exists.
Joe,
I tested this (setting up job numbers 0-9 with 1 digit specified in
Company
Config) and when you run out of job numbers, the system goes into an
endless
loop looking for the next job number. The only way out is to
CTRL-ALT-DEL
and End Task and then go into Company Config and change your job format.
This has been documented and has not yet been fixed.
-------------------
2-22-01 668792 - OPEN
Data collection does not force you to select a discrepant reason if you
report a discrepant qty.
2-22-01 669257 - OPEN - SCR 1806
Labor edit report takes much too long to run. About 10-15 minutes for
one day of one employee. Takes up to 30 minutes on slower computers.
Version 4 took about 30 seconds.
2-26-01 669996 - OPEN
Entry 2 is outside the range of list 794 (560)
This error occurs sometimes in data collection and labor entry when
ending an activity
This problem is only observed after installing patch 310.
2-26-01 Tech support feels there is something wrong with our jobs.
3-08-01 I have uploaded our database to epicor.
----------------
2-26-01 670350MPS - OPEN - SCR 1659
Various computers cannot run various programs when Vantage is running.
QC and the foreman's
office cannot run excel. Dave Stultz cannot run Autocad. Jodi cannot
run Winfax from
report Builder. Shelly and I cannot email from excel. This is a bug in
vantage. Users
should end-task on vantage.exe after starting vantage (vantage will stay
running).
The splash screen is stuck on causing this problem.
Running vantage from the command line (or a shortcut) can bypass this
problem.
Resolution:
SCR 1659, planned for Vantage 5.00
Tester's note: This problem occurs on some computers, such as Marcy's,
but
not others.
Prior to Cairo, the Vantage executable (vantage.exe) would go away when
Vantage took down the splash screen. As of Vantage 5.00.005 -- did not
find
an SCR for this change -- the vantage.exe program keeps running until
the
user exits Vantage. Per Development, the program should quit when the
splash screen comes down.
----------------
2-28-01 671497 - OPEN - SCR 1801
Joe,
The issue of firming up a job for MRP and getting an error if the next
job
number already exists has been written up. See document below:
Page ID 5032MPS
PROBLEM DESCRIPTION:
When attempting to firm up a job, if the next job number happens to be
the
same as one that is already in existence, a message comes up **JobHead
already exists for Company....(132)".
Duplicated in Mntech 5.00.310
1. Look in Company Config to see what the next job number is going to
be.
Manually add that job number (type it in along with the firm job prefix
that
is set up for your company or plant instead of using Next Job).
2. Bring up any unfirm job in Job Entry. Click the Firm check box.
Error
will occur. Click OK. The job entry screen shows the new job number in
the
job number field but doesn't actually create or overwrite the existing
job
number either (which it shouldn't).
3. Click on the search browser. The unfirm job is still unfirm. If you
try
to firm it again, it will advance to the next job number and will work
(unless that job number too has been manually entered in the past).
Firming
an MRP job should check the validity of the next job number and
automatically assign the next available number.
RESPONSE FROM DEVELOPMENT:
SCR 1801
When Cairo SCR 781 added prefixes for firm and unfirm jobs, it changed
Job
Entry (jc/jce10.w) to get the next job number without checking to see if
an
existing job already had that number. If one of the company's jobs
already
has the new number, the program should try a new one until it finds the
first unused job number.
------------------
3-5-01 673228 - OPEN
General Ledger report double spaces.
Clientele Call 673228MPS
Caller: - Joe Konecny Green Manufacturing Inc.
Phone: 419-352-9484x407
Product: General Ledger
Summary: GL - general ledger report is not lining up properly - looks
like
Cairo Bug.
3/5/2001 3:35:34 PM LBALLARD GL - general ledger report is not
lining up
properly - looks like Cairo Bug.
Steps to duplicate:
1. General Ledger
2. General Ledger Reports
3. Print detail
4. Print to your screen
You will notice that the lines are not lined up properly, thereby causes
extra spacing. This uses twice the amount of paper. In 4.00 this
report
does not double space and everything appears on one line.
3/5/2001 3:35:34 PM DGROSS sent e-mail to L-Development-Vantage Mgmt
sent e-mail to L-Development-Vantage Mgmt
3/6/2001 5:59:55 PM DGROSS SCR written
SCR 1813
When the Cairo 2D-3D project (SCR 784) changed the General Ledger Report
(gl/glr20-rp.w), it made a field too narrow, resulting in stair-stepping
in
the detail lines. The field lengths should go back to their original
widths
since a report has no three-dimensional fields.
------------------
3-7-01 673503 - OPEN
Can't use all of our data collection licenses.
3-7-01 Waiting on a .r program to tally licenses in use - Burt G.
3-8-01 We are still trying to test out the license counter. We have had
some users
report no errors and others reporting what your count was.
Will get it to you as soon as possible.
Thanks,
Burton L. Groenheim
------------------
3-7-01 674128 - OPEN
Cost set entry edit list takes hours to run.
Start add group 8:55
end add group 9:02
total time - 7 minutes
start rollup 9:02
end rollup 9:50
total time - 48 minutes
start preview edit list 9:53
end preview edit list: cancelled at 2:14pm
total time - unknown
------------------
3-9-01 674627 - OPEN
PO Invoice tracker vendor UOM is incorrect.
3-9-01 Verified by Wendy Peterson on our database.
------------------
3-8-01 674614 - OPEN
using vantagebasic...
"shellexec excel.exe" launches excel
"shellexec excel.exe c:\temp\test.xls" doesn't even launch excel. The
help file states this should work.
3-9-01 If you remove the ".exe" from the command it works.
3-12-01 Requested that the help file be changed.
------------------
3-9-01 675065 - OPEN
Discrepant qty in data collection does not backflush material.
------------------
3-12-01 675758 - OPEN
Discrepant QTY in data collection and labor entry is not explained
in the help.
3-12-01 Requested that the help file be changed.
-------------------
Date unknown 666102 - OPEN
APS Setup time field missing from part methods
-------------------
Date unknown 654346 - OPEN
W2 has incorrect wage info.
Hi Joe,
Development is working on this issue. I will keep you posted. Thanks,
Linda
-------------------
1-30-01 658757 - OPEN
Labor hours are wrong if shift passes midnight.
> I did it! I finally duplicated this, and it's sort of tricky. You need to-------------------
> Start Activity before midnight but actually click the OK button after you
> register your job, operation, etc AFTER the time rolls over to midnight. In
> other words, the employee needs to be in the middle of a labor entry when
> midnight rolls around. What then happens is this: the labor date for that
> particular labor detail is the date before midnight, so the total labor
> hours are as if the employee were there around the clock. I will submit
> this to Development and let you know what their response is.
>
> -----Original Message-----
> From: Joe Konecny [mailto:jkonecn@...]
> Sent: Tuesday, January 30, 2001 9:22 AM
> To: Craig Kumpula
> Subject: Re: Call Number 658757MPS Technical Support Reply: DC Employee
> shift from 23:00-07:00 and clocks in at 0:00 - hours are wrong
>
> Just an FYI... These continue to happen. It is definately
> reproducable here.
>
> Craig Kumpula wrote:
> >
> > Please reference call # 658757MPS if you have any additional questions on
> > this issue.
> >
> > Joe,
> >
> > I ran a test on my laptop over the weekend (4.00.904) to see if I could
> > duplicate this problem. I could not. I set up a shift for 23:00-07:00
> with
> > no lunch. I clocked an employee in at 22:50 (grace period rounded it up
> to
> > 23:00) and out at 07:16. I clocked him into a job right away and then out
> > at 23:59 (similar to the fax you sent of your Labor Edit report). I
> clocked
> > him into another job at 0:00 at out at 00:13, and then in and out of a
> > couple more jobs. The 00:00 - 00:13 entry correctly calculated as .22
> labor
> > hours.
> >
> > I suggest that you upload a copy of your database to our FTP site if you
> > continue to see problems. We could take a look at some examples in your
> > database (before you fix them) and see if we can determine what may be
> > causing this.
2-12-01 669499 - OPEN
Must turn off all shop warnings to make data collection work.
Patch 310 is supposed to fix this per Wendy at tech support.
We are testing as of 8:20am on 2-23-01.
v5 patch 310 does not fix the data collection bug about
shop warnings crashing data collection terminals.
I installed patch 310 on 2-23-01 at 3PM EST. At
9AM EST on 2-24-01 I turned shop warnings back on
in the company config. At 9:25am EST data collection
terminals started crashing with error messages stating
"Shopwrn in use by xxx". CPU utilization went to 100%
on both processors of a dual PIII 500Mhz terminal server
with 1G ram. Affected terminals had to be restarted.
Shop warnings had to be turned back off to make our system
operational again.
2/26/01 Matt Christus advised that server running the vantage
db needs to be rebooted for the patch to take effect. Will
test this theory asap.
2/27/01 Problem persists. Rebooting the server had no
effect.
3-8-01 Patch 312 supposedly fixes this but I have not tested it yet.
3-9-01 Tested - Still crashes
3-9-01 Sent Wendy export of shopwrn table.
-------------------
2-14-01 666086 - OPEN - SCR 1690
Entering a prefix in UNFIRM in comp config doesn't allow MRP to run.
If you don't enter a prefix MRP will run. In either case the
job number is 14 digits long.
MRP crashes when job number already exists.
Joe,
I tested this (setting up job numbers 0-9 with 1 digit specified in
Company
Config) and when you run out of job numbers, the system goes into an
endless
loop looking for the next job number. The only way out is to
CTRL-ALT-DEL
and End Task and then go into Company Config and change your job format.
This has been documented and has not yet been fixed.
> Duplicated in MNTech's 5.00.306prefix
>
> 1. Company config's job length set to 8
> 2. Firm Prefix = FRM. Unfirm Prefix = UNF.
> 3. Entered sales order for non-stock part and ran mrp net change
> 4. MRP created an unfirm job UNF00000000017.
> NOTE: I know we fixed an issue with there being a space between the prefix
> and the actual job number but this looks like an 11 digit job number.
> Shouldn't we only be padding it with 6 zeros if we are not counting the
> prefix as part of the job's length? Or 1 zero if we are counting the
> as a part of the job's length?to
> 5. Brought up the job in job entry and firmed it up.
> 6. A job number of FRM2618 was created. Again, if we aren't counting the
> prefix, shouldn't the job number be FRM00002618. Or if we are counting the
> prefix FRM02618?
>
> This inconsistency between the job length and what MRP creates is leading
> confusion.ignored
>
> RESPONSE FROM DEVELOPMENT:
>
> SCR 1690, planned for Vantage 5.00
>
> When Cairo SCR 781 added firm and unfirm prefixes to job numbers, it
> the company's job-number length. In MRP Processing, all unfirm jobs withtrimmed
> prefixes get a total length (including the prefix) of 14. In Job Entry,
> when an unfirm job with a prefix is firmed up, the numerical part is
> of any leading 0's. In both places, the programs should apply the company0's.
> job-number length to the numerical part of the job number, padding with
-------------------
2-22-01 668792 - OPEN
Data collection does not force you to select a discrepant reason if you
report a discrepant qty.
> Here is the status on another issue that you reported that I am submitting----------------
> to Development. I will let you know their response.
>
> Page ID 5011MPS
>
> PROBLEM DESCRIPTION:
> In version 4 in company config you could select to have the user forced to
> choose a reaons code for scrap (the check box Scrap Reasons). This appears
> not to be working completely in version 5.00. If a scrap quantity is
> reported in Data Collection, a Scrap Reason is required. But, if a
> Discrepant Qty is reported, a reason is not required, even though the field
> becomes activitated. It should either work on the same setting in Company
> Config as Scrap Reasons, or there should be a new setting in Company Config
> called Discrepant Reasons.
>
> Duplicated in Mntech 5.00.310
>
> 1. Go to Company Configuration, Module Configuration, Data Collection and
> make sure the check box Scrap Reasons is checked.
> 2. Log into a valid job and operation through Data Collection.
> 3. End Activity and report a scrap quantity. The reason code box becomes
> activated. Leave it blank and click OK. A message comes up indicating that
> you must enter a scrap reason code.
> 4. Put in a scrap reason code. Then enter a discrepant quantity. The
> resonon code box next to discrepant quantity becomes activated. Leave it
> blank. Click OK to exit the window. No discrepant code is required. This
> creates a non conformance, which does not show up in Inspection Processing
> until you go into Non Conformance entry and assign a reason code. (See
> related document 3765MPS, SCR 518.)
2-22-01 669257 - OPEN - SCR 1806
Labor edit report takes much too long to run. About 10-15 minutes for
one day of one employee. Takes up to 30 minutes on slower computers.
Version 4 took about 30 seconds.
> They found the problem with why the Labor Edit report was running so slow----------------
> with the SCR issued below. It will be fixed on a future Vantage release.
>
> Phil Berglund,
> Vantage Support
>
> SCR 1806
>
> When Cairo AXL 16153 (now SCR 1565) replaced the Progress use-index phrase
> in order to work with SQLServer databases, it changed the indexes used in
> the Labor Edit Report (jc/jcr20-rp.w). I suggest comparing the indexes with
> those used in the Morocco version, and seeing if you can get the old ones
> back.
2-26-01 669996 - OPEN
Entry 2 is outside the range of list 794 (560)
This error occurs sometimes in data collection and labor entry when
ending an activity
This problem is only observed after installing patch 310.
2-26-01 Tech support feels there is something wrong with our jobs.
3-08-01 I have uploaded our database to epicor.
----------------
2-26-01 670350MPS - OPEN - SCR 1659
Various computers cannot run various programs when Vantage is running.
QC and the foreman's
office cannot run excel. Dave Stultz cannot run Autocad. Jodi cannot
run Winfax from
report Builder. Shelly and I cannot email from excel. This is a bug in
vantage. Users
should end-task on vantage.exe after starting vantage (vantage will stay
running).
The splash screen is stuck on causing this problem.
Running vantage from the command line (or a shortcut) can bypass this
problem.
Resolution:
SCR 1659, planned for Vantage 5.00
Tester's note: This problem occurs on some computers, such as Marcy's,
but
not others.
Prior to Cairo, the Vantage executable (vantage.exe) would go away when
Vantage took down the splash screen. As of Vantage 5.00.005 -- did not
find
an SCR for this change -- the vantage.exe program keeps running until
the
user exits Vantage. Per Development, the program should quit when the
splash screen comes down.
----------------
2-28-01 671497 - OPEN - SCR 1801
Joe,
The issue of firming up a job for MRP and getting an error if the next
job
number already exists has been written up. See document below:
Page ID 5032MPS
PROBLEM DESCRIPTION:
When attempting to firm up a job, if the next job number happens to be
the
same as one that is already in existence, a message comes up **JobHead
already exists for Company....(132)".
Duplicated in Mntech 5.00.310
1. Look in Company Config to see what the next job number is going to
be.
Manually add that job number (type it in along with the firm job prefix
that
is set up for your company or plant instead of using Next Job).
2. Bring up any unfirm job in Job Entry. Click the Firm check box.
Error
will occur. Click OK. The job entry screen shows the new job number in
the
job number field but doesn't actually create or overwrite the existing
job
number either (which it shouldn't).
3. Click on the search browser. The unfirm job is still unfirm. If you
try
to firm it again, it will advance to the next job number and will work
(unless that job number too has been manually entered in the past).
Firming
an MRP job should check the validity of the next job number and
automatically assign the next available number.
RESPONSE FROM DEVELOPMENT:
SCR 1801
When Cairo SCR 781 added prefixes for firm and unfirm jobs, it changed
Job
Entry (jc/jce10.w) to get the next job number without checking to see if
an
existing job already had that number. If one of the company's jobs
already
has the new number, the program should try a new one until it finds the
first unused job number.
------------------
3-5-01 673228 - OPEN
General Ledger report double spaces.
Clientele Call 673228MPS
Caller: - Joe Konecny Green Manufacturing Inc.
Phone: 419-352-9484x407
Product: General Ledger
Summary: GL - general ledger report is not lining up properly - looks
like
Cairo Bug.
3/5/2001 3:35:34 PM LBALLARD GL - general ledger report is not
lining up
properly - looks like Cairo Bug.
Steps to duplicate:
1. General Ledger
2. General Ledger Reports
3. Print detail
4. Print to your screen
You will notice that the lines are not lined up properly, thereby causes
extra spacing. This uses twice the amount of paper. In 4.00 this
report
does not double space and everything appears on one line.
3/5/2001 3:35:34 PM DGROSS sent e-mail to L-Development-Vantage Mgmt
sent e-mail to L-Development-Vantage Mgmt
3/6/2001 5:59:55 PM DGROSS SCR written
SCR 1813
When the Cairo 2D-3D project (SCR 784) changed the General Ledger Report
(gl/glr20-rp.w), it made a field too narrow, resulting in stair-stepping
in
the detail lines. The field lengths should go back to their original
widths
since a report has no three-dimensional fields.
------------------
3-7-01 673503 - OPEN
Can't use all of our data collection licenses.
3-7-01 Waiting on a .r program to tally licenses in use - Burt G.
3-8-01 We are still trying to test out the license counter. We have had
some users
report no errors and others reporting what your count was.
Will get it to you as soon as possible.
Thanks,
Burton L. Groenheim
------------------
3-7-01 674128 - OPEN
Cost set entry edit list takes hours to run.
Start add group 8:55
end add group 9:02
total time - 7 minutes
start rollup 9:02
end rollup 9:50
total time - 48 minutes
start preview edit list 9:53
end preview edit list: cancelled at 2:14pm
total time - unknown
------------------
3-9-01 674627 - OPEN
PO Invoice tracker vendor UOM is incorrect.
3-9-01 Verified by Wendy Peterson on our database.
------------------
3-8-01 674614 - OPEN
using vantagebasic...
"shellexec excel.exe" launches excel
"shellexec excel.exe c:\temp\test.xls" doesn't even launch excel. The
help file states this should work.
3-9-01 If you remove the ".exe" from the command it works.
3-12-01 Requested that the help file be changed.
------------------
3-9-01 675065 - OPEN
Discrepant qty in data collection does not backflush material.
------------------
3-12-01 675758 - OPEN
Discrepant QTY in data collection and labor entry is not explained
in the help.
3-12-01 Requested that the help file be changed.