FYI...

4 new bugs added on 3-19-01

Newest ones are on the bottom...

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

676528

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

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

Joe,

Discrepant material should backflush, so this is a confirmed bug. See
the
write-up below:

Page ID 5110MPS

PROBLEM DESCRIPTION:
Backflushing does not work for discrepant quantity that is reported
either
in Labor Entry or Data Collection. Scrap quantity does backflush, but
discrepant quantity does not. In 4.0, defective quantity and good
quantity
both backflushed material for a related operation.

Duplicated in Mntech 5.00.312

1. Create a job with at least one operation and add a backflushed
material
related to that operation.
2. Engineer, release, and schedule the job.
3. Report a quantity complete in either Labor Entry or Data Collection.
First report a labor quantity and a Scrap quantity.
4. Look at the production detail report or in Job Tracker. Notice that
the
correct quantity was backflushed for the labor quantity and the scrap
quantity.
5. Add another labor entry, this time with a discrepant quantity. Note
that
the issued material does not change. The quantity that is reported as
Discrepant does not backflush.

RESPONSE FROM DEVELOPMENT:

SCR 1864

When Cairo SCR 981 added a discrepant quantity, it did not change the
backflush code (db/trg/labordtl/bckflush.i) to backflush the quantity.
The
code should handle discrepant material the same way as it treats scrap.

**************************************************************
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.
**************************************************************
3-13-01 676012 - CLOSED

Earned hours does not include time from parts run under setup.

Joe,

Development's response on this was that the earned hours are working as
designed. I created an enhancement request, see below:

************************************************************
*** Page ID: 5174MPS
*** Status: Suggestion
*** Created On: Mar 15 2001
*** Changed On: Mar 15 2001
*** Added By: Craig Kumpula
*** Product: VANTAGE
************************************************************
PROBLEM DESCRIPTION: Currently, the EarnedHours calculation for setup
does
not include a factor for quantity reported. Typically, there would be
at
least a few pieces run as part of setup that are good pieces and will
reduce
the quantity needed for the production run. Therefore, the calculation
for
earned hours should include the quantity reported in setup.
To view problem:
1. Create a job for 1000 pcs with an op with .5 hours setup and a prod
standard of 10 pcs/hr.
2. Reports a 100% complete setup and a quantity of 10 pcs completed in
setup.
3. Vantage shows only .5 earned hours. The 1 hour he should have earned
from production of the 10 pieces is not calculated because he was
clocked
into setup, not production.

PROBLEM RESOLUTION:
Currenty, Vantage is working as designed. Since the setup phase by
definition involves more than just producing pieces, we cannot compare
it to
the time in pure production. Customer's suggestion, however, would be
to
have Vantage do one of the following rather than not include the hours
at
all:

(1) Do the following calculation: Take the SetupEarned hours (.5) and
then
get a ProductionEarned hours from the pcs/rate... (1 hour) and add
those
together (TotalEarned) and divide by the burden hours to get efficiency.
Then take the SetupEarned/TotalEarned to give a percent of setup hours
in
the total. From this you get distributed setup hours from the reported
hours. Then take the ProductionEarned/TotalEarned to get a percent of
production hours in the total. From this you get distributed production
hours from the reported hours.
(2) Allow production and setup to be run on the same job/asm/op at the
same
time.
(3) Don't allow a completed qty when running setup.

Craig Kumpula
eManufacturing Support
Epicor Software Corporation
www.epicor.com
Phone: (800) 269-3044
Fax: (952) 582-5568
ckumpula@...
3-15-01 - CLOSED
**************************************************************
3-14-01 676933 - OPEN
Wendy

Lock table overflow when posting cost set entry group.
We can not post new standard cost!!!!!!!

Locks (-L) are currently set to 50048.

3-19-01 Received the following from Wendy...

Please reference call # 676933MPS if you have any additional questions
on
this issue.

Hi Joe,

Your Issue: In Coste Set Entry while trying to Post Group receiving -L
Locktable overflow (915).

RESPONSE: I submitted this issue to our Development Team and an SCR was
written. Please watch for fix on an upcoming patch. See document
below.

Page ID 5151MPS

ABOM - Cost Set Entry when Posting customer is getting -L locktable
overflow...
error message (915).

Customer is trying to post his Group in Cost Set Entry. Receiving
increase
-L parameter error (915) customers -L is set at 50048.

Steps to Duplicate:

1. Go to Cost Set Entry.
2. Select Group Kim.
3. Post Group.
4. It will run for approx. 1 1/2 - 2 hours and then you will receive
this
error message: -L Locktable Overflow (915). Customer has his -L set at
50048.

SCR 1870

Since its creation, as part of Cairo SCR 709, the program that posts
Cost
Sets (bm/bmp50-pt.w) has locked all the cost-part records. It only
needs to
lock one at a time.

WORKAROUND: Use smaller groups of parts.

If you need any further assistance with this issue, please contact me.

Wendy Peterson
eMfg Production Support

**************************************************************
3-19-01 677900 - OPEN
Virginia

When logging in, users sometimes get an error message...

** LicUsers already exists with UserNum 1. (132)
OK

Then the message repeats with the x of "usernum x"
incrementing up to 19 or 20. Then you finally get
in.
3-19-01 Virginia sent a program to unlock the licenses. Only way to fix
this is to make everyone exit Vantage and run the fix program.
3-19-01 Called Burt asking why this happens. Appears to be related to
issue 673503. He said it looks like there is a bug causing it.
Development is looking at it.
**************************************************************
3-19-01 677984 - OPEN
Craig

Print traveller dialog box in Job Tracker prevents data collection
users from starting/ending activity.

JobHead in use by bbarrin, 247 on 27.
Wait or choose CANCEL to stop (2624)
CANCEL

Joe,

I was able to duplicate this in your database in Data Collection by
going to
Job Tracker, print previewing the traveler, leaving the Print Job
Traveler/Production Detail Report box open, then ending activity for an
employee on that job. The attached print screens are the two error
messages
I got. The second error locked up Vantage and I had to end task. I was
only able to duplicate this in your database, not in ours, so I'm not
sure
why that is. I am sending the issue to Development and will let you
know
what they say.

Craig Kumpula

Page ID 5190MPS

PROBLEM DESCRIPTION:
Logging out of an activity after another user has print previewed a
traveler
on the same job causes the following error messages to occur: "JobHead
in
use by XXXX on XXXXX. Wait or choose CANCEL to stop. (2624)" Wait a
few
seconds and another error comes up "Disconnect from server, server
received
invalid message code (2661)". After this second error, Vantage locks up
and
the user must end task.

Duplicated on customer 5.00 database, eMfg7, 2840/tcp (not able to
duplicate
in our Mntech database)

1. Go into Job Tracker for any released job. Click the printer icon to
print the traveler.
2. Close the print preview screen, but leave the Print Job
Traveler/Production Detail Report window open.
3. Have another user on another work station log into the same job
through
Data Collection. No errors occur during log in. Have the user End
Activity
on the job. Errors occur.

Note: User suggested that the new field, TravelerLastPrinted, could be
causing this problem. This field gets updated in the JobHead table when
a
traveler is printed and could be causing a conflict for any update of
job
records. It should not be a problem though because printing a traveler
is
not actually changing any other job records.

RESPONSE FROM DEVELOPMENT:

SCR 1961

Since Cairo SCR 917 began saving the last-printed date inn the Job
Traveler/Production Detail Report front end (jc/jcr10-nm.w), the program
has
locked the job header record and held it until the user leaves the
program.
The record should be released as soon as the last-printed date is saved.

3-19-01 This affects two stations running job tracker also.

**************************************************************
3-19-01 678305 - OPEN
Phil

Running total in the transaction history is changing as misc issues
happen.

**************************************************************
3-19-01 678351 - OPEN
Phil

Issue to Mfg - Misc Issue does not force you to enter
a reason code. "Use inventory adjustment reasons" is
turned on in the company config.

Here's the document I submitted reporting your issue with the Misc Issue
and
reason codes.

Phil Berglund, Vantage
Support

Page ID 5187MPS

031901

Detailed Summary
----------------------------
Issues to Manufacturing, Misc Issue, you should not be allowed to click
OK
to save this transaction if the reason code is left blank. It lets
users
do this.

Steps to Reproduce
--------------------------------
1. IM > Gen Ops > Issues to Manufacturing.

2. Choose the Misc Issue button. Will create a STK-UKN transaction.

3. Choose part and quantity.

4. The Reason Code (RC) dropdown is available since the box for RC is
checked under Inventory Management configuration.

5. But it allows you to leave this field empty, click OK, save this
tranaction and leave the screen.

6. A user feels the RC should be required before leaving this screen
to
be consistent with other functions, such as Quantity Adjustments, which
wont
let you leave until you provide the RC.

**************************************************************