V5 bug list

Yahoo Archive
1
--- 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.

> 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.
-------------------

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.306
>
> 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
prefix
> as a part of the job's length?
> 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
to
> confusion.
>
> RESPONSE FROM DEVELOPMENT:
>
> SCR 1690, planned for Vantage 5.00
>
> When Cairo SCR 781 added firm and unfirm prefixes to job numbers, it
ignored
> the company's job-number length. In MRP Processing, all unfirm jobs with
> 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
trimmed
> of any leading 0's. In both places, the programs should apply the company
> job-number length to the numerical part of the job number, padding with
0's.
-------------------

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-27-01 670965 OPEN - SCR 1716

Cost set entry: Rollup function takes 5+ hours to complete.
2-28-01 Left running overnight and never did complete. Had to
kill the process.

Page ID 4901MPS

ABOM - cost set entry taking over a hour to run
Test Results: It took over an hour in customers databases. Another
customer reported 3 hours and 45 minutes . Their -L parameters have
been
set to 25024.

ABOM > General Operations > Select Group >Cost set entry - Get Parts >
Get
Operations > Get work centers > Roll Up > this procedure runs and runs.
I
have tested it in Thiels Database (emfg3 2530/tcp) and Vermont
Composites (
emfg6 2590/tcp) I do not know how long they took to run. I left after
one
hour.


SCR 1716, planned for Vantage 5.00

When Cairo cost-rollup improvements (SCR 709) created the cost-part
(CostPart) table, it gave it an index for the company, group, type code
(purchased or manufactured), and part number. But bm/rollcostset.w
looks up
the cost-part for just the company, group, and part number. Adding the
part's type code to the search should speed up performance.

Developer's note: More than one search needs to be fixed.
3-8-01 Patch 312 supposedly fixes this but I have not tested it yet.
----------------

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.
------------------
3-9-01 ? - OPEN

PO Invoice tracker vendor UOM is incorrect.
------------------
2
Several people have asked me the status of several v5 bugs.

Here is an updated list...

--- Vantage v5 bug list ---
-------------------
Date unknown 666102 - OPEN

APS Setup time field missing from part methods
-------------------
2-14-01 664107 - OPEN

Purchase order does not change from NEW to CHANGE when the
PO is modified.

SCR 1703

When the Cairo Purchase Limits project (SCR 432) changed the way
Purchase
Order Entry (pm/pme10.w) refreshed the screen after a user updated a
line,
it stopped redisplaying the Print As radio button. It needs to do that
since the PO likely has changed after the user updates a line.

WORKAROUND: Re-selecting the PO will bring in the correct Print As
value.
Also, the printed PO is correct.
-------------------
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.
-------------------
2-13-01 665612 - OPEN
From: GWACHTE To: JKONECN
JOE:

NEW INVENTORY USAGE REPORT HAS A BUG. PART CLASS SELECTION DOES NOT
WORK.
GIVES MORE THAN THE CLASS SELECTED.

Joe,

The issue of the Inventory Usage Report part class filter not working
has
been written up. See doc below:

Page ID 4927MPS

PROBLEM DESCRIPTION:

The Inventory Usage Report doesn't work properly when filtering by part
class.

Duplicated in Mntec 5.00.308

STEPS TO DUPLICATE:
1. Open the Inventory Usage report under Inventory Management-->Reports.
2. Select only one part class.
3. Run the report. Print it (or print preview) and notice that there
are
other part classes on the report than what you had selected. All part
classes are not listed, but more than what was selected are definitely
being
displayed on the report.

RESPONSE FROM DEVELOPMENT:

SCR 1736, planned for Vantage 5.00

When Cairo SCR 1281 added the part-class filter to the Inventory Usage
Report -- not mentioned in the SCR itself, it displayed any part (for
the
company) where any part class was in the part-class list. This is too
general: the report should look for any part where the part's part
class is
in the list.

-------------------
2-14-01 666086 - OPEN

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.306
>
> 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
prefix
> as a part of the job's length?
> 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
to
> confusion.
>
> RESPONSE FROM DEVELOPMENT:
>
> SCR 1690, planned for Vantage 5.00
>
> When Cairo SCR 781 added firm and unfirm prefixes to job numbers, it
ignored
> the company's job-number length. In MRP Processing, all unfirm jobs with
> 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
trimmed
> of any leading 0's. In both places, the programs should apply the company
> job-number length to the numerical part of the job number, padding with
0's.
-------------------
2-15-01 665560 - OPEN

Labor edit report does not show idle time when run by department. This
problem has existed since v4.
------------------
2-15-01 666976 - OPEN

PO unit of measure is incorrect on in PO suggestions. MAJOR PROBLEM!!!
Right now we are manually correcting each and every PO!!!!!
> Joe,
>
> I was able to duplicate the issue of the wrong UM being used in PO
> Suggestions. See below for steps. I have submitted it to Development and I
> will let you know what their response is.
>
> PROBLEM DESCRIPTION:
> If a selling unit of measure is set up for a part, the incorrect unit of
> measure and purchasing factor is used in PO Suggestions.
>
> Duplicated in Mntech 5.00.310
>
> 1. Set up a part in the part master with an inventory unit of measure, a
> purchasing UM and a selling UM. (For example, SH, LB, EA - see Mntech
> example part number SS-125) Use a different factor for each unit of
> measure.
> 2. Create a job with a purchase direct requirement for this part and
> generate PO suggestions.
> 3. Look at the PO Suggestions (new). Note that the factor is not used, the
> vendor quantity is wrong, and the unit of measure is wrong for the vendor.
>
------------------
2-16-01 667332 - OPEN

When adding a sales order release the make direct flag is stuck on
even on stock parts. This only happens on orders that existed on v4.
-----------------
2-20-01 667721 - OPEN

How does cost entry group work?
-----------------
2-20-01 667995 - OPEN

From: GWACHTE To: JKONECN
JOE:

PROBLEM WITH TRYING TO DUPLICATE A PO IN PURCHASE MGMT.
WHEN DUPLICATING A CLOSED PO, THE NEW PO LINE ITEMS ARE ALSO CLOSED AND
IT
WILL NOT LET YOU DELETE ANY OF THE LINES YOU DO NOT WANT.

GARY

Hi Joe,

Your Issue: When duplicating a closed PO.

Response: A similar issue has been reported and already fixed this
issue.

The fix will be on an upcoming patch (.311 or later). See document
below.


4965 MPS PM - when duplicating a closed PO the lines can not be deleted
error message stating that material transactions exist ...

Steps to Duplicate: Duplicated on MnTech 5.00.310

1. Go to Purchase Order Entry.
2. Click on binculars to find a closed PO with more than one line. I
used
PO #103.
3. Go to Order > Duplicate Order > Created PO #221 >
4. The lines were duplicated. The status on each of the lines is
Closed.
5. Go to Lines > Reopen.
6. Try to delete one of the lines - receive error message that states
that
material transactions exist. But, I just created this new PO and there
have
not been any transaction against it.
7. Now go back to the Original PO 103 this was a closed PO with both
line
items closed. Now the PO is open and the lines are also.

A similar issue has been reported with a PO line's job number, but SCR
1722,
fixed for Vantage 5.00.311, resolves this issue as well. The problem is
that when you duplicate a PO, the PO lines on the screen are still from
the
old PO.

WORKAROUND:
The workaround is to bring up the new PO again, either by getting out
and
back into PO Entry or by selecting a different PO and then selecting the
new
PO, instead of going into it immediately after duplicating.
-----------------
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

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-20-01 667647 - OPEN

Can't run standard cost rollup. "lock table overflow" error.
Locks currently set to 25024 per tech support recommendation.
Tech support says to try -L 50000. Not tested yet.
----------------
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.
----------------
2-26-01 670350MPS - OPEN

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.
----------------
3
Here was a change I forgot to include...

2-20-01 667647 - CLOSED

Can't run standard cost rollup. "lock table overflow" error.
Locks currently set to 25024 per tech support recommendation.
Tech support says to try -L 50000. Not tested yet.
2-27-01 Tested with -L 50048. Works now.
----------------