--- 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
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.
Hi Joe,
Your Issue: ShopWrn in use by error.
Response: Our Development Team has written an SCR on this issue.
Please
watch for fix on an upcoming 5.00 patch.
Page ID 5225 MPS
Summary: SW ShopWrn in use by (2624) (2661) while in DC, Labor Entry
or
running Labor Edit Report...
STEPS TO DUPLICATE:
1. Go into Job Managment > Reports > Labor Edit Report > Run this
report
for all employees/all Departments / with dates of 01/01/01 - 03/23/01
(todays date - I believe this is important) Print Preview is checked.
2. Another user went into Job Management > General Operations > Labor
Entry
2624
SCR 2022, planned for Vantage 5.00
Tester's note: The easiest way to duplicate this is with the Green
database
(MNTECH, emfg7), using the steps in this call.
Since Cairo SCR 345 consolidated Global Alerts and Shop Warnings
processing
into one program (xa/xap05.p), the program has exited without doing
anything
if a global alert is not active, which is correct. Shop warnings do not
have an Active checkbox; the assumption is that it is inactive if no
toggle
boxes are checked. But the program treats all shop warnings as active.
As
a result, a lot more shop warnings get created in Vantage 5.00 than in
Vantage 4.00. To make things worse, once the program finds the shop
warning
with an exclusive lock, it does not release the lock. It should not
need to
lock more than one warning at a time, and should exit without doing
anything
if no warning is needed.
If you need any further assistance with this issue, please contact me.
Wendy Peterson
eMfg Production Support
**************************************************************
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 - CLOSED - 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 - CLOSED - 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.
3-28-01 Fixed
**************************************************************
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-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-28-01 Supposedly fixed but don't want to test because rollup
calculates incorrectly.
4-2-01 Reluctant to test this because costs cannot be verified
since the report won't work. See 674128
**************************************************************
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.
Joe:
Here's the doc I submitted on the running total problem you reported
recently.
Phil Berglund, Vantage
Support
Page ID 5204MPS
032101
Detailed Summary
-----------------------------
The running total in transaction history will be distorted after adding
Misc
Issues from Issues to Manufacturing.
Steps to Reproduce
---------------------------------
1. For a part in the Part Tracker > Transaction history, the
running
total will initially be correct for existing transactions.
2. Go to Inv Mgt > General Ops > Issues to Mfg > Misc Issue.
3. Issue a positive or negative quantity here.
4. Go back to the part tracker > Trans History. The running total
can
be distorted for the initial transactions that existed in step 1. It
appears to recalculate incorrectly.
5. To see this, look in the MNTECH 5.00.312 database and note the
effects of these transactions on parts otp-test and 1032FW. A user
reports a similar problem and we can test on their database, too, which
is
here.
4-02-01 Awaiting test results from Gary
**************************************************************
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.
**************************************************************
3-20-01 676270 - OPEN - Submitted by Allegheny Bradford Corporation
Please reference call # 676270MPS if you have any additional questions
on
this issue.
Hi Gail,
Your Issue: 5107MPS Â QM Error (3230)while loading salvage material on
a
material requirement.
Response: This issue was submitted to Development and a Software Change
Request has been written. Please watch for fix on an upcoming patch.
See
Document below.
Steps to Duplicate:
1. Add quote
2. Add Line
3. Get details
4. Update Material requirement to add salvage material > Click on
search
browser for salvage part number. Here is where you will receive the
error.
"mismatched parameter typres passed to procedure GetInvCost Total
eq/eqe10Âsl (3230)
3/13/01 6:35:32 PM DGROSS SCR written
SCR 1845
When Cairo SCR 740 added costing by lots, it added another parameter to
the
GetInvCostTotal procedure. But the SCR overlooked Quote Salvage Entry
(eq/eqe10Âsl.w). I suggest looking for all calls to the procedure, to
make
sure that the parameters are correct.
If you need any further assistance with this issue, please contact me.
Wendy Peterson
**************************************************************
3-23-01 680113 - OPEN
Craig
Cost set entry does not appear to roll up the correct amount
for material, labor and burden compared to the BOM cost
report. Part 600-2741 is an example.
The issue of Cost Set rollup not working correctly is a known bug and is
being addressed by Development. Basically, as you can see towards the
end
of the document below, you will have to run the rollup for each level in
order to get the correct cost.
*********
NOTE: The Cost Roll Up Functionality has changed in Version 5.0. See
Document Below. The document describes how it is currently working.
This
is a known issue and Development is currently working on it.
In 5.00, SCR 1064 introduced a change that caused the BOM Cost Report
(Advance Bill of Material > Reports > BOM Cost Report) and the View Cost
button (found in Inv Mgmt > Part Master > Revision > BOM) to not use the
part master cost for non-standard costed subassemblies instead of
rolling up
the related method.
The two issues are:
1. We have taken away functionality from 4.00. Many users used this
report
and view to see what the rolled up cost of the method was regardless of
the
costing method of the subassemblies. Now, with a multi-level assembly,
the
subassemblies do not get rolled up but instead their part master costs
are
used.
If I have a single level BOM, these two features will correctly roll up
the
method even though the part is not standard costed. This inconsistency
between main level and subassembly adds to the confusion.
2. For non-stock subassemblies that are not standard costed, we are
forcing
the user to maintain the part master costs manually to be able to
utilize the report in 5.00 in the same manner they did in 4.00.
If I am building a multi-level assembly in 5.00 and it has a non-stock
subassembly, I want to know based on its method what it will cost me,
not
whatever the part master cost is because I don't stock it and never
will.
However, to get the same functionality out of the report and view, I
would
have to manually update the part master costs for each assembly.
What we need is to give the user the option of whether or not they want
the
subassemblies rolled up in the report and view no matter what the
costing
method is.
Steps to duplicate:
1. Create 2 parts in the part master file. Part Sub is a subassembly
whose
method contains one operation and one material. Part Parent is the
parent
assembly whose method contains the same operation and same material as
part
Sub's method and also contains part Sub as a subassembly that is marked
as
pull and view as assembly. Make sure that both parts are average costed
and
do not do any cost adjustments.
2. Run the BOM cost and look at the costs via the View Costs button.
Notice
that only the costs related to the parent item are given because the
subassembly is average costed. But yet we roll up the parent item's
method
to get the parent level's cost even though it too is also average
costed.
The above issue gets even deeper if we throw Cost Set Entry into the
mix.
1. Create 3 parts in the part master file. Part Sub2 is a subassembly
that
has one material and one operation. Part Sub is a subassembly whose
method
contains the same material and operation as Sub2 and also contains Sub2
as a
subassembly marked pull and view as assembly. Part Parent is the
parent
assembly whose method contains the same material and operation as Sub2
and
also contains part Sub as a subassembly marked as view and pull as
assembly.
Basically, we've created a 3 level assembly where each level has the
identical costs because the material and operations attached to each
level
is identical. Make sure that each part is average costed and do not do
any
cost adjustments.
2. Create a Cost Set group using the option of Costing Method. Note that
all
three parts default into the group at zero. (Assume that each level has
a
total cost related to the method of $7.50).
Running the cost rollup once produces the following costs as displayed
in
the cost group:
Parent = $15.00
Sub = $7.50
Sub2 = $7.50
Run the rollup again against the same cost set and notice the following
costs:
Parent = $15.00
Sub = $15.00
Sub2 = $7.50
One more time, run the rollup against the same cost set and notice the
following:
Parent = $22.50
Sub = $15.00
Sub2 = $7.50
I had to run the rollup 3 times (once for each level) so that the cost
of
the parent item is correct. I can then replace the Standard cost for
this
part if I wanted to but all I really wanted to do in this example is to
see
what my total cost was for the parent item based on the rollup of all
three
levels. DO NOT POST THIS GROUP see step 3.
3. Do not post the cost set created in the above step. Instead, go back
to
the part master and make Sub2, Sub and Parent all standard costed.
Create
another cost set using the selection criteria of Costing Method. Notice
the
costs that default into the three parts.
4. Run the cost rollup once. Notice that the costs correctly display as:
Parent = $22.50
Sub = $15.00
Sub2 = $7.50
The above changes has made the visibility of costs of non-standard
costed
assemblies that do not hit inventory very difficult to view.
Craig Kumpula
**************************************************************
3-23-01 680190 - OPEN
Wendy
Your Issue: DMR's are adding to on hand qty.
Response: This is a known issue, that is currently being worked on by
our
Development Team. This issue is marked as "High Priority". Watch for
fix
on an upcoming patch. See Document Below.
Page ID 5114MPS
PROBLEM DESCRIPTION:
It appears that INS-DMR transactions are increasing the on hand quantity
if
you look at the running total in transaction history. Actually, the
problem
is not that the on-hand quanity in the part master is changing, but the
transaction history report has some issues:
1. Create a part in the part master file.
2. Do a quantity adjustment to add 1,000 pcs to create an on-hand qty.
3. Create a non-conformance from inventory for 500 pcs
4. Inspect the 500 pcs and send them to DMR
5. Go to the part tracker and look at the transaction history.
Note that the ADJ-QTY for 1,000 pcs now has a running total of 500
instead
of 1,000.
The STK-INS transaction for 500 pcs brings the running total down to 0
and
the INS-DMR
transaction brings the running total back up to 500.
Look at the on-hand quantity for the part and you'll see that it
correctly
states 500 pcs but by looking at the transaction history and then the
on-hand it appears that the INS-DMR transaction has increased your
inventory. This happens whether or not the dmr warehouse is attached to
the
part in the part master file.
RESPONSE FROM DEVELOPMENT:
SCR 1820
Since Cairo SCR 1500 added a running total to the Part Transaction
History
(xa/xai10-th.w), the program has changed the total for INS-DMR
transactions.
An INS-DMR needs to have no effect on the running total.
If you need any further assistance with this issue, please contact me.
Wendy Peterson
eMfg Production Support
4-02-01 Tested again. Still doesn't work.
**************************************************************
**************************************************************
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.
Hi Joe,
Your Issue: ShopWrn in use by error.
Response: Our Development Team has written an SCR on this issue.
Please
watch for fix on an upcoming 5.00 patch.
Page ID 5225 MPS
Summary: SW ShopWrn in use by (2624) (2661) while in DC, Labor Entry
or
running Labor Edit Report...
STEPS TO DUPLICATE:
1. Go into Job Managment > Reports > Labor Edit Report > Run this
report
for all employees/all Departments / with dates of 01/01/01 - 03/23/01
(todays date - I believe this is important) Print Preview is checked.
2. Another user went into Job Management > General Operations > Labor
Entry
> Used Emp 1152 Added Time > Add detail (020798 Job Number operation 50)click OK, This is where you will receive the error. ShopWrn in use by
2624
SCR 2022, planned for Vantage 5.00
Tester's note: The easiest way to duplicate this is with the Green
database
(MNTECH, emfg7), using the steps in this call.
Since Cairo SCR 345 consolidated Global Alerts and Shop Warnings
processing
into one program (xa/xap05.p), the program has exited without doing
anything
if a global alert is not active, which is correct. Shop warnings do not
have an Active checkbox; the assumption is that it is inactive if no
toggle
boxes are checked. But the program treats all shop warnings as active.
As
a result, a lot more shop warnings get created in Vantage 5.00 than in
Vantage 4.00. To make things worse, once the program finds the shop
warning
with an exclusive lock, it does not release the lock. It should not
need to
lock more than one warning at a time, and should exit without doing
anything
if no warning is needed.
If you need any further assistance with this issue, please contact me.
Wendy Peterson
eMfg Production Support
**************************************************************
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 - CLOSED - 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 slow3-28-01 Fixed
> 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 - CLOSED - 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.
3-28-01 Fixed
**************************************************************
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-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-28-01 Supposedly fixed but don't want to test because rollup
calculates incorrectly.
4-2-01 Reluctant to test this because costs cannot be verified
since the report won't work. See 674128
**************************************************************
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.
Joe:
Here's the doc I submitted on the running total problem you reported
recently.
Phil Berglund, Vantage
Support
Page ID 5204MPS
032101
Detailed Summary
-----------------------------
The running total in transaction history will be distorted after adding
Misc
Issues from Issues to Manufacturing.
Steps to Reproduce
---------------------------------
1. For a part in the Part Tracker > Transaction history, the
running
total will initially be correct for existing transactions.
2. Go to Inv Mgt > General Ops > Issues to Mfg > Misc Issue.
3. Issue a positive or negative quantity here.
4. Go back to the part tracker > Trans History. The running total
can
be distorted for the initial transactions that existed in step 1. It
appears to recalculate incorrectly.
5. To see this, look in the MNTECH 5.00.312 database and note the
effects of these transactions on parts otp-test and 1032FW. A user
reports a similar problem and we can test on their database, too, which
is
here.
4-02-01 Awaiting test results from Gary
**************************************************************
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.
**************************************************************
3-20-01 676270 - OPEN - Submitted by Allegheny Bradford Corporation
Please reference call # 676270MPS if you have any additional questions
on
this issue.
Hi Gail,
Your Issue: 5107MPS Â QM Error (3230)while loading salvage material on
a
material requirement.
Response: This issue was submitted to Development and a Software Change
Request has been written. Please watch for fix on an upcoming patch.
See
Document below.
Steps to Duplicate:
1. Add quote
2. Add Line
3. Get details
4. Update Material requirement to add salvage material > Click on
search
browser for salvage part number. Here is where you will receive the
error.
"mismatched parameter typres passed to procedure GetInvCost Total
eq/eqe10Âsl (3230)
3/13/01 6:35:32 PM DGROSS SCR written
SCR 1845
When Cairo SCR 740 added costing by lots, it added another parameter to
the
GetInvCostTotal procedure. But the SCR overlooked Quote Salvage Entry
(eq/eqe10Âsl.w). I suggest looking for all calls to the procedure, to
make
sure that the parameters are correct.
If you need any further assistance with this issue, please contact me.
Wendy Peterson
**************************************************************
3-23-01 680113 - OPEN
Craig
Cost set entry does not appear to roll up the correct amount
for material, labor and burden compared to the BOM cost
report. Part 600-2741 is an example.
The issue of Cost Set rollup not working correctly is a known bug and is
being addressed by Development. Basically, as you can see towards the
end
of the document below, you will have to run the rollup for each level in
order to get the correct cost.
*********
NOTE: The Cost Roll Up Functionality has changed in Version 5.0. See
Document Below. The document describes how it is currently working.
This
is a known issue and Development is currently working on it.
In 5.00, SCR 1064 introduced a change that caused the BOM Cost Report
(Advance Bill of Material > Reports > BOM Cost Report) and the View Cost
button (found in Inv Mgmt > Part Master > Revision > BOM) to not use the
part master cost for non-standard costed subassemblies instead of
rolling up
the related method.
The two issues are:
1. We have taken away functionality from 4.00. Many users used this
report
and view to see what the rolled up cost of the method was regardless of
the
costing method of the subassemblies. Now, with a multi-level assembly,
the
subassemblies do not get rolled up but instead their part master costs
are
used.
If I have a single level BOM, these two features will correctly roll up
the
method even though the part is not standard costed. This inconsistency
between main level and subassembly adds to the confusion.
2. For non-stock subassemblies that are not standard costed, we are
forcing
the user to maintain the part master costs manually to be able to
utilize the report in 5.00 in the same manner they did in 4.00.
If I am building a multi-level assembly in 5.00 and it has a non-stock
subassembly, I want to know based on its method what it will cost me,
not
whatever the part master cost is because I don't stock it and never
will.
However, to get the same functionality out of the report and view, I
would
have to manually update the part master costs for each assembly.
What we need is to give the user the option of whether or not they want
the
subassemblies rolled up in the report and view no matter what the
costing
method is.
Steps to duplicate:
1. Create 2 parts in the part master file. Part Sub is a subassembly
whose
method contains one operation and one material. Part Parent is the
parent
assembly whose method contains the same operation and same material as
part
Sub's method and also contains part Sub as a subassembly that is marked
as
pull and view as assembly. Make sure that both parts are average costed
and
do not do any cost adjustments.
2. Run the BOM cost and look at the costs via the View Costs button.
Notice
that only the costs related to the parent item are given because the
subassembly is average costed. But yet we roll up the parent item's
method
to get the parent level's cost even though it too is also average
costed.
The above issue gets even deeper if we throw Cost Set Entry into the
mix.
1. Create 3 parts in the part master file. Part Sub2 is a subassembly
that
has one material and one operation. Part Sub is a subassembly whose
method
contains the same material and operation as Sub2 and also contains Sub2
as a
subassembly marked pull and view as assembly. Part Parent is the
parent
assembly whose method contains the same material and operation as Sub2
and
also contains part Sub as a subassembly marked as view and pull as
assembly.
Basically, we've created a 3 level assembly where each level has the
identical costs because the material and operations attached to each
level
is identical. Make sure that each part is average costed and do not do
any
cost adjustments.
2. Create a Cost Set group using the option of Costing Method. Note that
all
three parts default into the group at zero. (Assume that each level has
a
total cost related to the method of $7.50).
Running the cost rollup once produces the following costs as displayed
in
the cost group:
Parent = $15.00
Sub = $7.50
Sub2 = $7.50
Run the rollup again against the same cost set and notice the following
costs:
Parent = $15.00
Sub = $15.00
Sub2 = $7.50
One more time, run the rollup against the same cost set and notice the
following:
Parent = $22.50
Sub = $15.00
Sub2 = $7.50
I had to run the rollup 3 times (once for each level) so that the cost
of
the parent item is correct. I can then replace the Standard cost for
this
part if I wanted to but all I really wanted to do in this example is to
see
what my total cost was for the parent item based on the rollup of all
three
levels. DO NOT POST THIS GROUP see step 3.
3. Do not post the cost set created in the above step. Instead, go back
to
the part master and make Sub2, Sub and Parent all standard costed.
Create
another cost set using the selection criteria of Costing Method. Notice
the
costs that default into the three parts.
4. Run the cost rollup once. Notice that the costs correctly display as:
Parent = $22.50
Sub = $15.00
Sub2 = $7.50
The above changes has made the visibility of costs of non-standard
costed
assemblies that do not hit inventory very difficult to view.
Craig Kumpula
**************************************************************
3-23-01 680190 - OPEN
Wendy
Your Issue: DMR's are adding to on hand qty.
Response: This is a known issue, that is currently being worked on by
our
Development Team. This issue is marked as "High Priority". Watch for
fix
on an upcoming patch. See Document Below.
Page ID 5114MPS
PROBLEM DESCRIPTION:
It appears that INS-DMR transactions are increasing the on hand quantity
if
you look at the running total in transaction history. Actually, the
problem
is not that the on-hand quanity in the part master is changing, but the
transaction history report has some issues:
1. Create a part in the part master file.
2. Do a quantity adjustment to add 1,000 pcs to create an on-hand qty.
3. Create a non-conformance from inventory for 500 pcs
4. Inspect the 500 pcs and send them to DMR
5. Go to the part tracker and look at the transaction history.
Note that the ADJ-QTY for 1,000 pcs now has a running total of 500
instead
of 1,000.
The STK-INS transaction for 500 pcs brings the running total down to 0
and
the INS-DMR
transaction brings the running total back up to 500.
Look at the on-hand quantity for the part and you'll see that it
correctly
states 500 pcs but by looking at the transaction history and then the
on-hand it appears that the INS-DMR transaction has increased your
inventory. This happens whether or not the dmr warehouse is attached to
the
part in the part master file.
RESPONSE FROM DEVELOPMENT:
SCR 1820
Since Cairo SCR 1500 added a running total to the Part Transaction
History
(xa/xai10-th.w), the program has changed the total for INS-DMR
transactions.
An INS-DMR needs to have no effect on the running total.
If you need any further assistance with this issue, please contact me.
Wendy Peterson
eMfg Production Support
4-02-01 Tested again. Still doesn't work.
**************************************************************