I would like to be taken off this mailing list
-----Original Message-----
From:
vantage@yahoogroups.com [mailto:
vantage@yahoogroups.com]
Sent: Friday, January 24, 2003 6:57 AM
To:
vantage@yahoogroups.com
Subject: [Vantage] Digest Number 2246
Useful links for the Yahoo!Groups Vantage Board are: ( Note: You must have
already linked your email address to a yahoo id to enable access. )
(1) To access the Files Section of our Yahoo!Group for Report Builder and
Crystal Reports and other 'goodies', please goto:
http://groups.yahoo.com/group/vantage/files/.
(2) To search through old msg's goto:
http://groups.yahoo.com/group/vantage/messages
(3) To view links to Vendors that provide Vantage services goto:
http://groups.yahoo.com/group/vantage/links
------------------------------------------------------------------------
There are 6 messages in this issue.
Topics in this digest:
1. RE: Call 838043 - Winco Industries
From:
ams@...
2. RE: Time Out / Shutdown utilities can corrupt Vantage d ata.
From: "Winter, Patrick" <
pjw@...>
3. RE: Time Out / Shutdown utilities can corrupt Vantage data. -- and
more...
From: "Jeff Lewis" <
jeff@...>
4. RE: Time Out / Shutdown utilities can corrupt Vantage d ata.
From: Thad Jacobs <
tjacobs@...>
5. RE: Time Out / Shutdown utilities can corrupt Vantage d ata. -- and
more...
From: Todd Anderson <
tanderson@...>
6. RE: Time Out / Shutdown utilities can corrupt Vantage d ata. -- and
more...
From: Thad Jacobs <
tjacobs@...>
________________________________________________________________________
________________________________________________________________________
Message: 1
Date: Thu, 23 Jan 2003 17:29:59 -0500
From:
ams@...
Subject: RE: Call 838043 - Winco Industries
I got around this by two ways.
One I modified the standard VTG files to reference a different ini file
which I call vanbase.ini, that way even if the vantage.ini is modified it
does not affect most users. Second, I found that if you change the access
permissions on the ini files to read-only for everyone (even you) then the
installs won't try (or simply can't) modify the file. Whenever you need to
make changes you simply change the permissions, make your changes and then
set them back. These methods seem to work pretty well without too much
effort.
Mercer Sisson
-----Original Message-----
From: Dunn, Nancy [mailto:
ndunn@...]
Sent: Monday, January 20, 2003 1:08 PM
To: Vantage Onelist (E-mail)
Subject: [Vantage] Call 838043 - Winco Industries
I don't have a document number for this one, but if you are interested give
Support a call.
Thanks Nancy
****************************************************************
To: 'Luanne Peterson'
Subject: RE: Call 838043
SUGGESTED ENHANCEMENT:
Custom parameter is being overwritten in the Propath line of the Vantage.ini
file, (sample: PROPATH=.,W:\Custom,W:\Vantage), every time a client install
is done.
Each time a client install is ran, the Vantage.ini file must be edited so
the Custom programming will be used.
PURPOSE:
I would like to see a check box added to the Vantage, so when a client
install is done Vantage will know the Custom parameter should be put back
into the .INI file.
It's a real hassle trying to remember to put the option back in every time
there is an install. If it is forgotten the Custom programming is not used.
Yahoo! Groups Sponsor
ADVERTISEMENT
<
http://rd.yahoo.com/M=241773.2861420.4212388.1925585/D=egroupweb/S=17050071
83:HM/A=1394045/R=0/*
http://www.hgtv.com/hgtv/pac_ctnt/text/0,,HGTV_3936_580
2,FF.html> HGTV Dream Home Giveaway
<
http://us.adserver.yahoo.com/l?M=241773.2861420.4212388.1925585/D=egroupmai
l/S=:HM/A=1394045/rand=330118115>
Useful links for the Yahoo!Groups Vantage Board are: ( Note: You must have
already linked your email address to a yahoo id to enable access. )
(1) To access the Files Section of our Yahoo!Group for Report Builder and
Crystal Reports and other 'goodies', please goto:
http://groups.yahoo.com/group/vantage/files/.
<
http://groups.yahoo.com/group/vantage/files/.>
(2) To search through old msg's goto:
http://groups.yahoo.com/group/vantage/messages
<
http://groups.yahoo.com/group/vantage/messages>
(3) To view links to Vendors that provide Vantage services goto:
http://groups.yahoo.com/group/vantage/links
<
http://groups.yahoo.com/group/vantage/links>
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<
http://docs.yahoo.com/info/terms/> .
[Non-text portions of this message have been removed]
________________________________________________________________________
________________________________________________________________________
Message: 2
Date: Thu, 23 Jan 2003 16:32:02 -0600
From: "Winter, Patrick" <
pjw@...>
Subject: RE: Time Out / Shutdown utilities can corrupt Vantage d ata.
Are you tell us not to use the Progress Time Out Utility?
Patrick Winter
-----Original Message-----
From: Thad Jacobs [mailto:
tjacobs@...]
Sent: Thursday, January 23, 2003 4:18 PM
To: '
vantage@yahoogroups.com'
Subject: [Vantage] Time Out / Shutdown utilities can corrupt Vantage data.
Just to reiterate a key point, and at the risk of sounding redundant, if
anyone is using a time out utility, or any program that performs a hard
shut-down of vantage or the client machine it is running on, they run the
likely risk of transactions being halted midstream.
Of course, one of the inherent flaws of the classic client-server
architecture is that when business logic is running on the client side is
that an application relies heavily on the client workstation for
transactional integrity. I look forward to Sonoma, which will have all the
business logic running on the server.
Until we're on Sonoma, though, I'd strongly recommend that we all suspend
the use of time-out and auto-shutdown utilities on data-entry workstations,
or at least only use programs that will gracefully shutdown vantage and back
out any open transactions (if there are such programs). I imagine that past
use of such utilities are likely to continue to create anomalies that
unnecessarily eat up both ours and Epicor's time.
Yes, you can tell users not to leave transactions open when they leave their
desks, but staking referential integrity entirely on a user's organic memory
is not best course of action. When it gets down to it, the database is
running on our clock, not theirs, and though we can' t prevent them from
making typos, the problems generated when vantage is forced to crash in the
middle of a transaction fall completely within our jurisdiction as DB
Administrators.
One may wonder why Epicor hasn't built into vantage a timeout function.
Yes, it would end up detracting slightly from their licensing revenue.
However, they have created the feature that disallows multiple open
instances per workstation, which shows me that they are open to implementing
features that save customers licensing costs, because customer satisfaction
is key to their survival.
By putting in a time-out utility, Epicor would be designing a feature into
their program that hinders user productivity and moral. How would you like
it if you were typing an important e-mail, left for lunch, and came back
only to find that Outlook had crashed because your boss doesn't want to buy
sufficient CAL's for exchange? How likely would you be to recommend
Outlook/Exchange to colleagues?
All our employers are making a huge investment in client licenses for
vantage, because there is a consensus that Vantage user licenses are worth
the money wey pay for them. Yes, A time-out utility may be of great use on
pc's on which we can absolutely guarantee no transactions originate from
(assuming no user productivity is lost due repeatedly having to log back on)
On data entry workstations, though, it is a corner cut that is already
resulting in data corruption and nearly untraceable descrepancies vantage
databases.
Thaddeus Jacobs
IT Developer
Kinematic Automation, Inc.
mailto:
tjacobs@... <mailto:
tjacobs@...>
-----Original Message-----
From: Troy Funte [mailto:
tfunte@...]
Sent: Thursday, January 23, 2003 11:15 AM
To:
vantage@yahoogroups.com
Subject: Re: [Vantage] Inventory Not Updating Correctly
Update on this issue:
We were able to replicate a situation with the Timeout Utility (Mike's)
that leaves an orphaned record in PartTran. Here's how I reproduced the
problem.
1. Enter the Receipt from Manufacturing screen, and select a job to "Receive
from Inventory".. Enter a Qty of 1 or more.
2. Now let the Timeout Utility kill the Vantage session (in your test
database, of course).
The result: In PartTran for the part, there will be a MFG-STK transaction
with the Qty entered, but the OnHandQty will not be updated by the orphaned
transaction. In addition, the job header does not record that the product
was received. This in turn makes it so that you cannot 'unreceive' the part
because you will get an error saying that no parts were received in the
first place. Running the Stock Status report for any past date will cause
it to see the transaction and calculate it, thus corrupting the Stock Status
report by the same amount.
My advice for Timeout Utility users is to alert your users to this possible
dangerous scenario and make sure they don't leave transactions partially
transacted when leaving their desk for any reason. I'm not sure if this
affects any other screens in Vantage, although we have had AP groups that
wouldn't post after the Timeout Utility left them hanging.
I believe there are still other possible issues with the Stock Status report
for past dates and possibly with OnHandQty's, but this is the main one for
us it appears.
Troy Funte
Liberty Electronics
----- Original Message -----
From: Troy Funte
To: vantage@yahoogroups.com
Sent: Monday, January 20, 2003 10:43 PM
Subject: Re: [Vantage] Inventory Not Updating Correctly
Good Questions, Lydia.
* I honestly don't know what impact having transaction dates back to
1969 would do. Obviously, Vantage would think you had some inventory back
on 1/1/1970 for a 1969 transaction. I don't think you can run the report
for further back than that.
* As far as the Inventory VALUES... if you've ever done a cycle count,
then your inventory in Vantage will be correct from that date forward... at
least until this 'bug' happens again. Also, you would be in the predicament
that, should you ever need to run the 'fixbinsall.r' to program, it would
sort of 'undo' what your cycle count did for those parts that may have been
affected by this in the past.
* I've checked past and future dates in our system, and there are none
that I can see. I used a crystal report to check the whole PartTran table
for any TranDate that was greater than TODAY or less than 1/1/1970.
* Lastly, in our case, the fixbinsall.r program (after running it on a
test database) cleans up the stock status completely. Running it on
1/1/1970 it says: Zero. I page of empty warehouses. If dates were an issue
for us, the fixbinsall.r would not have cleaned those up. In your case, the
old and new date problems could be clouding the issue quite a bit. I have a
Crystal report for Vantage 5.1 that will check to see what the Calculated
OnHandQty SHOULD be, and compares it to the current PartBin.OnHandQty. It
will show me if they are not equal -- which highlights the problem we are
discussing here.
I hope that made sense and clarifies things for you.
Troy Funte
Liberty Electronics
----- Original Message -----
From: Lydia Coffman
To: vantage@yahoogroups.com
Sent: Monday, January 20, 2003 6:55 PM
Subject: RE: [Vantage] Inventory Not Updating Correctly
I'm at a loss here -- if I run the stock status in the "way back"
machine, I
get 37 items that show up before Vantage was ever installed. However,
our
status and Inventory VALUES on the current report is correct -- I've
checked
them against our cycle count inventory that was completed today. We
have
never had a stk-mtl transaction that didn't work--but the dates aren't
always in your view. Try setting the date on Part tracker AHEAD a year,
or
even ten years.
Also, I am positive that there are transactions in my database(packing
slips
and invoices at least) that are dated 1989 and 1969 and 2010--we had a
very
bad combo of person making packing slips with the wrong date and invoice
clerk not double checking. That could account for quite a few errors in
the
6 years that we've had Vantage. Also, all but 2 of our items that
appear on
the "way back" are manufactured, not purchased. Maybe you had someone
receiving items with the wrong date at some point. Maybe you should
give a
look at packing slip tracker and see if you have packing slips dated
"way
back".
Vantage 5.1
Lydia
Canyon Engineering Products
lcoffman@...
----- Original Message -----
From: "Troy Funte" <tfunte@...>
To: <vantage@yahoogroups.com>
Sent: Friday, January 17, 2003 9:27 PM
Subject: Re: [Vantage] Inventory Not Updating Correctly
> We have had the very same SERIOUS issue. In fact, I have an open
issue
on this with Epicor now. We had the same problem in
Vantage 3.0 and 5.0, we are now seeing it in 5.1 as well. It has
caused
major problems with the integrity of our Inventory. I
still don't think Epicor knows how this happens exactly, although as you
have discovered, it seems to be pinpointed to STK-MTL
transactions not adjusting the OnHandQty correctly. You mention
purchased
parts only, but we have seen it with manufactured parts
as well (both subassemblies and top level parts, which tells me that it
may
not be limited to the STK-MTL transaction type).
> For us the problem was serious enough that we had a meeting with
Epicor
on it over a year ago -- partly to say, "if you know of
a problem like this, you should at least let user's know so that they
can
watch their inventory closer. And if we're having this
problem, other users are probably having it as well". They have not
acted
on that suggestion to date. (This suggestion was to
higher Epicor management, not Tech Support, by the way).
>
> I HAVE DISCOVED HOW TO SEE IF THIS PROBLEM EXISTS IN YOUR DATABASE BY
RUNNING A TEST YOUR STOCK STATUS REPORT. AFTER YOU TRY
THIS PROCEDURE, I WOULD BE LIKE TO HEAR FROM EVERYONE ON THE LIST WHO
FINDS
THIS PROBLEM -- IT CAN BE *VERY SERIOUS* FROM A
MATERIALS AND ACCOUNTING STANDPOINT.
>
> HERE'S WHAT YOU DO. Run the Stock Status report... but instead of
using
TODAY'S date, enter a date in the past that is far enough
back to precede your earliest transaction in your database. It may take
some
time to run. 1/1/1970 is a good date since it is
probably old enough to precede any installation of Vantage. Also, I'm
not
sure what logic Vantage uses for Date schemes, but if you
enter a date like 1/1/50, it may give you 2050 instead of 1950. Running
the
Stock Status for 1/1/70 should give you a ZERO dollar
Stock Status report with ZERO parts in stock. If you find ANY parts
listed
(positive or negative), note the part(s) and I'll bet
you a candy bar that your OnHandQty is wrong for that part(s). The
reason
this logic works is this: To find the OnHandQty for dates
prior to today, the Stock Status assumes the current OnHandQty is
correct
TODAY, and then it goes through each transaction
(PartTran) for a Part and subtracts/adds the quantity of that
transaction to
the current OnHandQty until it reaches the date you
entered. It calculates backwards from today. Thus, back in 1970 (at
least
from Vantage's perspective) the OnHandQty for every part
should be ZERO. Now you can use the list of parts from the report to
calculate the TRUE (calculated) OnHandQty. After you have
printed/written the list of parts, open up PartTracker. Find one of the
guilty parts that has the shortest transaction history.
Next, go line by line through each transaction and manually calculate
what
the OnHandQty should be. If your transacton history is
less that 50 transactions, you can do a quick check by scrolling to the
end
(bottom) of the transaction history to see if the first
running total is correct. (I say less than 50 transactions because
there is
still a known issue with the running totals being
inaccurate after more than 100 transactions. The issue used to involve
anything over 50 transactions, so I don't trust either).
>
> Epicor sent us a fix program (fixbinsall.r) back last year to
recalculate
all the OnHandQty's. The problem was, after it fixed
our OnHandQty's, our Stock Status changed by significant $$ dollars.
Additionally, any parts that were previously affected by this
bug, and which also had a Cylce Count done on them to correct the
OnHandQty
through a ADJ-QTY, these parts are now OFF again by the
amount of the ADJ-QTY. So even after running the 'fixbinsall.r'
program, we
weren't sure if our OnHandQty was right or not. We
ended up doing a complete Inventory Count on all 10,000+ parts in our
inventory to clarify the integrity our Stock Status. And now
to find out that the problem is still there is incredibly disconcerting.
In
these days of Enron scandals, this type of thing makes
our Controller VERY nervous and our auditors VERY suspicious. Auditor:
"Why
did your stock status change by thousands of dollars,
but we don't see it in your Cost of Sales or anywhere else for that
matter?"
Controller: "Well, we ran this fix program on our
database and it changed our stock status, but you won't see any
transactions
showing that it did so." Auditor: "What did the fix
program do?'". Controller: "It adjusted for a bug in the database that
causes it to not calculate our OnHandQty correctly. It goes
in and changes the OnHandQty if they are wrong." Auditor: "Which parts
did
it change?" Controller: "We don't know." Auditor: "O.K.
so the bug is fixed now then, right?". Controller: "No, the database
can
still cause OnHandQty's to be incorrect. We're not sure
when it happens or how often, or for how long it has been happening."
Auditor: "Do you know how to spell E-N-R-O-N? What has your
software company done about this, and when did you first know it
existed?"
Controller: "We brought the problem to their attention
over a year ago. There has been no bug fix for it, nor is there any SCR
written to fix it." Auditor: "Why are you still using this
software?" Controller: "Good question."
>
> Michael. Thanks for bringing this to our attention. And as I
mentioned,
I would love to see how many Vantage Customers this is
affecting and by how many $$ dollars. I assume it could be hundreds of
users
if not 100% of the Vantage userbase. I had assumed up
until about a month ago that this bug was fixed in 5.1, but I have
verified
in our current database that it is not. I would have to
assume it is still a problem in 5.2 as it has never been addressed in a
patch to this date (in addition to the fact that if your
OnHandQty's were off in 5.1 or any earlier version, those OnHandQty's
would
be brought right into 5.2 as well.
>
> Sorry for the long letter. I believe this issue is serious enough that
users should be aware and vigilant. Sometimes to be TOO
brief is to invite misunderstanding.
>
> With much gravity,
>
> Troy Funte
> Liberty Electronics
>
>
> ----- Original Message -----
> From: Michael Benedict
> To: vantage@yahoogroups.com
> Sent: Friday, January 17, 2003 10:04 AM
> Subject: [Vantage] Inventory Not Updating Correctly
>
>
> A part number was brought to my attention this morning that showed a
balance
> of 289 onhand but there were actually zero. I went back and
reviewed
the
> Tran History on the part and noticed several instances where STK-MTL
> transactions were not updating the inventory. The transactions
appear,
but
> the Running Total Column and it appears now the Inventory was not
updated
> correctly. This problem appears to have occurred sporadically since
we
> installed Vantage 4.0 in 1999, we are now on 5.0. The problem only
occurs
> on Purchased Parts and only for STK-MTL transactions. I pulled a
few of
our
> most frequently used materials up in part tracker and it occurs at
some
> point in all parts. There is no common link to the parts and a
transaction
> performed less than one minute after and incorrect transaction will
be
> correct. Has anyone else had this issue before?
>
> Thanks,
>
> Michael Benedict
> IS Manager
> Crestview Aerospace Corp.
>
>
> Yahoo! Groups Sponsor
> ADVERTISEMENT
>
>
>
>
> Useful links for the Yahoo!Groups Vantage Board are: ( Note: You
must
have already linked your email address to a yahoo id to
enable access. )
> (1) To access the Files Section of our Yahoo!Group for Report
Builder
and Crystal Reports and other 'goodies', please goto:
http://groups.yahoo.com/group/vantage/files/.
<http://groups.yahoo.com/group/vantage/files/.>
> (2) To search through old msg's goto:
http://groups.yahoo.com/group/vantage/messages
<http://groups.yahoo.com/group/vantage/messages>
> (3) To view links to Vendors that provide Vantage services goto:
http://groups.yahoo.com/group/vantage/links
<http://groups.yahoo.com/group/vantage/links>
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>
>
> [Non-text portions of this message have been removed]
>
>
>
> Useful links for the Yahoo!Groups Vantage Board are: ( Note: You must
have already linked your email address to a yahoo id to
enable access. )
> (1) To access the Files Section of our Yahoo!Group for Report Builder
and
Crystal Reports and other 'goodies', please goto:
http://groups.yahoo.com/group/vantage/files/.
<http://groups.yahoo.com/group/vantage/files/.>
> (2) To search through old msg's goto:
http://groups.yahoo.com/group/vantage/messages
<http://groups.yahoo.com/group/vantage/messages>
> (3) To view links to Vendors that provide Vantage services goto:
http://groups.yahoo.com/group/vantage/links
<http://groups.yahoo.com/group/vantage/links>
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/ <http://docs.yahoo.com/info/terms/>
>
Useful links for the Yahoo!Groups Vantage Board are: ( Note: You must
have
already linked your email address to a yahoo id to enable access. )
(1) To access the Files Section of our Yahoo!Group for Report Builder
and
Crystal Reports and other 'goodies', please goto:
http://groups.yahoo.com/group/vantage/files/.
<http://groups.yahoo.com/group/vantage/files/.>
(2) To search through old msg's goto:
http://groups.yahoo.com/group/vantage/messages
<http://groups.yahoo.com/group/vantage/messages>
(3) To view links to Vendors that provide Vantage services goto:
http://groups.yahoo.com/group/vantage/links
<http://groups.yahoo.com/group/vantage/links>
Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/ <http://docs.yahoo.com/info/terms/>
Yahoo! Groups Sponsor
ADVERTISEMENT
Useful links for the Yahoo!Groups Vantage Board are: ( Note: You must
have already linked your email address to a yahoo id to enable access. )
(1) To access the Files Section of our Yahoo!Group for Report Builder
and Crystal Reports and other 'goodies', please goto:
http://groups.yahoo.com/group/vantage/files/.
<http://groups.yahoo.com/group/vantage/files/.>
(2) To search through old msg's goto:
http://groups.yahoo.com/group/vantage/messages
<http://groups.yahoo.com/group/vantage/messages>
(3) To view links to Vendors that provide Vantage services goto:
http://groups.yahoo.com/group/vantage/links
<http://groups.yahoo.com/group/vantage/links>
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
[Non-text portions of this message have been removed]
Yahoo! Groups Sponsor
ADVERTISEMENT
Useful links for the Yahoo!Groups Vantage Board are: ( Note: You must
have already linked your email address to a yahoo id to enable access. )
(1) To access the Files Section of our Yahoo!Group for Report Builder and
Crystal Reports and other 'goodies', please goto:
http://groups.yahoo.com/group/vantage/files/.
<http://groups.yahoo.com/group/vantage/files/.>
(2) To search through old msg's goto:
http://groups.yahoo.com/group/vantage/messages
<http://groups.yahoo.com/group/vantage/messages>
(3) To view links to Vendors that provide Vantage services goto:
http://groups.yahoo.com/group/vantage/links
<http://groups.yahoo.com/group/vantage/links>
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
[Non-text portions of this message have been removed]
Yahoo! Groups Sponsor
ADVERTISEMENT
<http://rd.yahoo.com/M=241773.2861422.4212389.1925585/D=egroupweb/S=17050071
83:HM/A=1394046/R=0/*http://www.hgtv.com/hgtv/pac_ctnt/text/0,,HGTV_3936_580
2,FF.html> HGTV Dream Home Giveaway
<http://us.adserver.yahoo.com/l?M=241773.2861422.4212389.1925585/D=egroupmai
l/S=:HM/A=1394046/rand=188020319>
Useful links for the Yahoo!Groups Vantage Board are: ( Note: You must have
already linked your email address to a yahoo id to enable access. )
(1) To access the Files Section of our Yahoo!Group for Report Builder and
Crystal Reports and other 'goodies', please goto:
http://groups.yahoo.com/group/vantage/files/.
<http://groups.yahoo.com/group/vantage/files/.>
(2) To search through old msg's goto:
http://groups.yahoo.com/group/vantage/messages
<http://groups.yahoo.com/group/vantage/messages>
(3) To view links to Vendors that provide Vantage services goto:
http://groups.yahoo.com/group/vantage/links
<http://groups.yahoo.com/group/vantage/links>
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> .
[Non-text portions of this message have been removed]
Useful links for the Yahoo!Groups Vantage Board are: ( Note: You must have
already linked your email address to a yahoo id to enable access. )
(1) To access the Files Section of our Yahoo!Group for Report Builder and
Crystal Reports and other 'goodies', please goto:
http://groups.yahoo.com/group/vantage/files/.
(2) To search through old msg's goto:
http://groups.yahoo.com/group/vantage/messages
(3) To view links to Vendors that provide Vantage services goto:
http://groups.yahoo.com/group/vantage/links
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
________________________________________________________________________
________________________________________________________________________
Message: 3
Date: Thu, 23 Jan 2003 16:31:39 -0600
From: "Jeff Lewis" <jeff@...>
Subject: RE: Time Out / Shutdown utilities can corrupt Vantage data. -- and
more...
So can power outages, application lockups that freeze the OS, and a user
that thinks you turn off a computer by pressing the button on the front.
Jeff
-----Original Message-----
From: Thad Jacobs [mailto:tjacobs@...]
Sent: Thursday, January 23, 2003 4:18 PM
To: 'vantage@yahoogroups.com'
Subject: [Vantage] Time Out / Shutdown utilities can corrupt
Vantage data.
Just to reiterate a key point, and at the risk of sounding
redundant, if
anyone is using a time out utility, or any program that performs
a hard
shut-down of vantage or the client machine it is running on,
they run the
likely risk of transactions being halted midstream.
Of course, one of the inherent flaws of the classic
client-server
architecture is that when business logic is running on the
client side is
that an application relies heavily on the client workstation for
transactional integrity. I look forward to Sonoma, which will
have all the
business logic running on the server.
Until we're on Sonoma, though, I'd strongly recommend that we
all suspend
the use of time-out and auto-shutdown utilities on data-entry
workstations,
or at least only use programs that will gracefully shutdown
vantage and back
out any open transactions (if there are such programs). I
imagine that past
use of such utilities are likely to continue to create anomalies
that
unnecessarily eat up both ours and Epicor's time.
Yes, you can tell users not to leave transactions open when they
leave their
desks, but staking referential integrity entirely on a user's
organic memory
is not best course of action. When it gets down to it, the
database is
running on our clock, not theirs, and though we can' t prevent
them from
making typos, the problems generated when vantage is forced to
crash in the
middle of a transaction fall completely within our jurisdiction
as DB
Administrators.
One may wonder why Epicor hasn't built into vantage a timeout
function.
Yes, it would end up detracting slightly from their licensing
revenue.
However, they have created the feature that disallows multiple
open
instances per workstation, which shows me that they are open to
implementing
features that save customers licensing costs, because customer
satisfaction
is key to their survival.
By putting in a time-out utility, Epicor would be designing a
feature into
their program that hinders user productivity and moral. How
would you like
it if you were typing an important e-mail, left for lunch, and
came back
only to find that Outlook had crashed because your boss doesn't
want to buy
sufficient CAL's for exchange? How likely would you be to
recommend
Outlook/Exchange to colleagues?
All our employers are making a huge investment in client
licenses for
vantage, because there is a consensus that Vantage user licenses
are worth
the money wey pay for them. Yes, A time-out utility may be of
great use on
pc's on which we can absolutely guarantee no transactions
originate from
(assuming no user productivity is lost due repeatedly having to
log back on)
On data entry workstations, though, it is a corner cut that is
already
resulting in data corruption and nearly untraceable
descrepancies vantage
databases.
Thaddeus Jacobs
IT Developer
Kinematic Automation, Inc.
mailto:tjacobs@... <mailto:tjacobs@...>
-----Original Message-----
From: Troy Funte [mailto:tfunte@...]
Sent: Thursday, January 23, 2003 11:15 AM
To: vantage@yahoogroups.com
Subject: Re: [Vantage] Inventory Not Updating Correctly
Update on this issue:
We were able to replicate a situation with the Timeout
Utility (Mike's)
that leaves an orphaned record in PartTran. Here's how I
reproduced the
problem.
1. Enter the Receipt from Manufacturing screen, and select a job
to "Receive
from Inventory".. Enter a Qty of 1 or more.
2. Now let the Timeout Utility kill the Vantage session (in your
test
database, of course).
The result: In PartTran for the part, there will be a MFG-STK
transaction
with the Qty entered, but the OnHandQty will not be updated by
the orphaned
transaction. In addition, the job header does not record that
the product
was received. This in turn makes it so that you cannot
'unreceive' the part
because you will get an error saying that no parts were received
in the
first place. Running the Stock Status report for any past date
will cause
it to see the transaction and calculate it, thus corrupting the
Stock Status
report by the same amount.
My advice for Timeout Utility users is to alert your users to
this possible
dangerous scenario and make sure they don't leave transactions
partially
transacted when leaving their desk for any reason. I'm not sure
if this
affects any other screens in Vantage, although we have had AP
groups that
wouldn't post after the Timeout Utility left them hanging.
I believe there are still other possible issues with the Stock
Status report
for past dates and possibly with OnHandQty's, but this is the
main one for
us it appears.
Troy Funte
Liberty Electronics
----- Original Message -----
From: Troy Funte
To: vantage@yahoogroups.com
Sent: Monday, January 20, 2003 10:43 PM
Subject: Re: [Vantage] Inventory Not Updating Correctly
Good Questions, Lydia.
* I honestly don't know what impact having transaction dates
back to
1969 would do. Obviously, Vantage would think you had some
inventory back
on 1/1/1970 for a 1969 transaction. I don't think you can run
the report
for further back than that.
* As far as the Inventory VALUES... if you've ever done a
cycle count,
then your inventory in Vantage will be correct from that date
forward... at
least until this 'bug' happens again. Also, you would be in the
predicament
that, should you ever need to run the 'fixbinsall.r' to program,
it would
sort of 'undo' what your cycle count did for those parts that
may have been
affected by this in the past.
* I've checked past and future dates in our system, and there
are none
that I can see. I used a crystal report to check the whole
PartTran table
for any TranDate that was greater than TODAY or less than
1/1/1970.
* Lastly, in our case, the fixbinsall.r program (after running
it on a
test database) cleans up the stock status completely. Running
it on
1/1/1970 it says: Zero. I page of empty warehouses. If dates
were an issue
for us, the fixbinsall.r would not have cleaned those up. In
your case, the
old and new date problems could be clouding the issue quite a
bit. I have a
Crystal report for Vantage 5.1 that will check to see what the
Calculated
OnHandQty SHOULD be, and compares it to the current
PartBin.OnHandQty. It
will show me if they are not equal -- which highlights the
problem we are
discussing here.
I hope that made sense and clarifies things for you.
Troy Funte
Liberty Electronics
----- Original Message -----
From: Lydia Coffman
To: vantage@yahoogroups.com
Sent: Monday, January 20, 2003 6:55 PM
Subject: RE: [Vantage] Inventory Not Updating Correctly
I'm at a loss here -- if I run the stock status in the "way
back"
machine, I
get 37 items that show up before Vantage was ever installed.
However,
our
status and Inventory VALUES on the current report is correct
-- I've
checked
them against our cycle count inventory that was completed
today. We
have
never had a stk-mtl transaction that didn't work--but the
dates aren't
always in your view. Try setting the date on Part tracker
AHEAD a year,
or
even ten years.
Also, I am positive that there are transactions in my
database(packing
slips
and invoices at least) that are dated 1989 and 1969 and
2010--we had a
very
bad combo of person making packing slips with the wrong date
and invoice
clerk not double checking. That could account for quite a
few errors in
the
6 years that we've had Vantage. Also, all but 2 of our
items that
appear on
the "way back" are manufactured, not purchased. Maybe you
had someone
receiving items with the wrong date at some point. Maybe
you should
give a
look at packing slip tracker and see if you have packing
slips dated
"way
back".
Vantage 5.1
Lydia
Canyon Engineering Products
lcoffman@...
----- Original Message -----
From: "Troy Funte" <tfunte@...>
To: <vantage@yahoogroups.com>
Sent: Friday, January 17, 2003 9:27 PM
Subject: Re: [Vantage] Inventory Not Updating Correctly
> We have had the very same SERIOUS issue. In fact, I
have an open
issue
on this with Epicor now. We had the same problem in
Vantage 3.0 and 5.0, we are now seeing it in 5.1 as well.
It has
caused
major problems with the integrity of our Inventory. I
still don't think Epicor knows how this happens exactly,
although as you
have discovered, it seems to be pinpointed to STK-MTL
transactions not adjusting the OnHandQty correctly. You
mention
purchased
parts only, but we have seen it with manufactured parts
as well (both subassemblies and top level parts, which tells
me that it
may
not be limited to the STK-MTL transaction type).
> For us the problem was serious enough that we had a
meeting with
Epicor
on it over a year ago -- partly to say, "if you know of
a problem like this, you should at least let user's know so
that they
can
watch their inventory closer. And if we're having this
problem, other users are probably having it as well". They
have not
acted
on that suggestion to date. (This suggestion was to
higher Epicor management, not Tech Support, by the way).
>
> I HAVE DISCOVED HOW TO SEE IF THIS PROBLEM EXISTS IN YOUR
DATABASE BY
RUNNING A TEST YOUR STOCK STATUS REPORT. AFTER YOU TRY
THIS PROCEDURE, I WOULD BE LIKE TO HEAR FROM EVERYONE ON THE
LIST WHO
FINDS
THIS PROBLEM -- IT CAN BE *VERY SERIOUS* FROM A
MATERIALS AND ACCOUNTING STANDPOINT.
>
> HERE'S WHAT YOU DO. Run the Stock Status report... but
instead of
using
TODAY'S date, enter a date in the past that is far enough
back to precede your earliest transaction in your database.
It may take
some
time to run. 1/1/1970 is a good date since it is
probably old enough to precede any installation of Vantage.
Also, I'm
not
sure what logic Vantage uses for Date schemes, but if you
enter a date like 1/1/50, it may give you 2050 instead of
1950. Running
the
Stock Status for 1/1/70 should give you a ZERO dollar
Stock Status report with ZERO parts in stock. If you find
ANY parts
listed
(positive or negative), note the part(s) and I'll bet
you a candy bar that your OnHandQty is wrong for that
part(s). The
reason
this logic works is this: To find the OnHandQty for dates
prior to today, the Stock Status assumes the current
OnHandQty is
correct
TODAY, and then it goes through each transaction
(PartTran) for a Part and subtracts/adds the quantity of
that
transaction to
the current OnHandQty until it reaches the date you
entered. It calculates backwards from today. Thus, back in
1970 (at
least
from Vantage's perspective) the OnHandQty for every part
should be ZERO. Now you can use the list of parts from the
report to
calculate the TRUE (calculated) OnHandQty. After you have
printed/written the list of parts, open up PartTracker.
Find one of the
guilty parts that has the shortest transaction history.
Next, go line by line through each transaction and manually
calculate
what
the OnHandQty should be. If your transacton history is
less that 50 transactions, you can do a quick check by
scrolling to the
end
(bottom) of the transaction history to see if the first
running total is correct. (I say less than 50 transactions
because
there is
still a known issue with the running totals being
inaccurate after more than 100 transactions. The issue used
to involve
anything over 50 transactions, so I don't trust either).
>
> Epicor sent us a fix program (fixbinsall.r) back last year
to
recalculate
all the OnHandQty's. The problem was, after it fixed
our OnHandQty's, our Stock Status changed by significant $$
dollars.
Additionally, any parts that were previously affected by
this
bug, and which also had a Cylce Count done on them to
correct the
OnHandQty
through a ADJ-QTY, these parts are now OFF again by the
amount of the ADJ-QTY. So even after running the
'fixbinsall.r'
program, we
weren't sure if our OnHandQty was right or not. We
ended up doing a complete Inventory Count on all 10,000+
parts in our
inventory to clarify the integrity our Stock Status. And now
to find out that the problem is still there is incredibly
disconcerting.
In
these days of Enron scandals, this type of thing makes
our Controller VERY nervous and our auditors VERY
suspicious. Auditor:
"Why
did your stock status change by thousands of dollars,
but we don't see it in your Cost of Sales or anywhere else
for that
matter?"
Controller: "Well, we ran this fix program on our
database and it changed our stock status, but you won't see
any
transactions
showing that it did so." Auditor: "What did the fix
program do?'". Controller: "It adjusted for a bug in the
database that
causes it to not calculate our OnHandQty correctly. It goes
in and changes the OnHandQty if they are wrong." Auditor:
"Which parts
did
it change?" Controller: "We don't know." Auditor: "O.K.
so the bug is fixed now then, right?". Controller: "No, the
database
can
still cause OnHandQty's to be incorrect. We're not sure
when it happens or how often, or for how long it has been
happening."
Auditor: "Do you know how to spell E-N-R-O-N? What has
your
software company done about this, and when did you first
know it
existed?"
Controller: "We brought the problem to their attention
over a year ago. There has been no bug fix for it, nor is
there any SCR
written to fix it." Auditor: "Why are you still using this
software?" Controller: "Good question."
>
> Michael. Thanks for bringing this to our attention. And
as I
mentioned,
I would love to see how many Vantage Customers this is
affecting and by how many $$ dollars. I assume it could be
hundreds of
users
if not 100% of the Vantage userbase. I had assumed up
until about a month ago that this bug was fixed in 5.1, but
I have
verified
in our current database that it is not. I would have to
assume it is still a problem in 5.2 as it has never been
addressed in a
patch to this date (in addition to the fact that if your
OnHandQty's were off in 5.1 or any earlier version, those
OnHandQty's
would
be brought right into 5.2 as well.
>
> Sorry for the long letter. I believe this issue is serious
enough that
users should be aware and vigilant. Sometimes to be TOO
brief is to invite misunderstanding.
>
> With much gravity,
>
> Troy Funte
> Liberty Electronics
>
>
> ----- Original Message -----
> From: Michael Benedict
> To: vantage@yahoogroups.com
> Sent: Friday, January 17, 2003 10:04 AM
> Subject: [Vantage] Inventory Not Updating Correctly
>
>
> A part number was brought to my attention this morning
that showed a
balance
> of 289 onhand but there were actually zero. I went back
and
reviewed
the
> Tran History on the part and noticed several instances
where STK-MTL
> transactions were not updating the inventory. The
transactions
appear,
but
> the Running Total Column and it appears now the
Inventory was not
updated
> correctly. This problem appears to have occurred
sporadically since
we
> installed Vantage 4.0 in 1999, we are now on 5.0. The
problem only
occurs
> on Purchased Parts and only for STK-MTL transactions. I
pulled a
few of
our
> most frequently used materials up in part tracker and it
occurs at
some
> point in all parts. There is no common link to the
parts and a
transaction
> performed less than one minute after and incorrect
transaction will
be
> correct. Has anyone else had this issue before?
>
> Thanks,
>
> Michael Benedict
> IS Manager
> Crestview Aerospace Corp.
>
>
> Yahoo! Groups Sponsor
> ADVERTISEMENT
>
>
>
>
> Useful links for the Yahoo!Groups Vantage Board are: (
Note: You
must
have already linked your email address to a yahoo id to
enable access. )
> (1) To access the Files Section of our Yahoo!Group for
Report
Builder
and Crystal Reports and other 'goodies', please goto:
http://groups.yahoo.com/group/vantage/files/.
<http://groups.yahoo.com/group/vantage/files/.>
> (2) To search through old msg's goto:
http://groups.yahoo.com/group/vantage/messages
<http://groups.yahoo.com/group/vantage/messages>
> (3) To view links to Vendors that provide Vantage
services goto:
http://groups.yahoo.com/group/vantage/links
<http://groups.yahoo.com/group/vantage/links>
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms
of Service.
>
>
> [Non-text portions of this message have been removed]
>
>
>
> Useful links for the Yahoo!Groups Vantage Board are: (
Note: You must
have already linked your email address to a yahoo id to
enable access. )
> (1) To access the Files Section of our Yahoo!Group for
Report Builder
and
Crystal Reports and other 'goodies', please goto:
http://groups.yahoo.com/group/vantage/files/.
<http://groups.yahoo.com/group/vantage/files/.>
> (2) To search through old msg's goto:
http://groups.yahoo.com/group/vantage/messages
<http://groups.yahoo.com/group/vantage/messages>
> (3) To view links to Vendors that provide Vantage services
goto:
http://groups.yahoo.com/group/vantage/links
<http://groups.yahoo.com/group/vantage/links>
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
<http://docs.yahoo.com/info/terms/>
>
Useful links for the Yahoo!Groups Vantage Board are: ( Note:
You must
have
already linked your email address to a yahoo id to enable
access. )
(1) To access the Files Section of our Yahoo!Group for
Report Builder
and
Crystal Reports and other 'goodies', please goto:
http://groups.yahoo.com/group/vantage/files/.
<http://groups.yahoo.com/group/vantage/files/.>
(2) To search through old msg's goto:
http://groups.yahoo.com/group/vantage/messages
<http://groups.yahoo.com/group/vantage/messages>
(3) To view links to Vendors that provide Vantage services
goto:
http://groups.yahoo.com/group/vantage/links
<http://groups.yahoo.com/group/vantage/links>
Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
<http://docs.yahoo.com/info/terms/>
Yahoo! Groups Sponsor
ADVERTISEMENT
Useful links for the Yahoo!Groups Vantage Board are: ( Note:
You must
have already linked your email address to a yahoo id to enable
access. )
(1) To access the Files Section of our Yahoo!Group for
Report Builder
and Crystal Reports and other 'goodies', please goto:
http://groups.yahoo.com/group/vantage/files/.
<http://groups.yahoo.com/group/vantage/files/.>
(2) To search through old msg's goto:
http://groups.yahoo.com/group/vantage/messages
<http://groups.yahoo.com/group/vantage/messages>
(3) To view links to Vendors that provide Vantage services
goto:
http://groups.yahoo.com/group/vantage/links
<http://groups.yahoo.com/group/vantage/links>
Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service.
[Non-text portions of this message have been removed]
Yahoo! Groups Sponsor
ADVERTISEMENT
Useful links for the Yahoo!Groups Vantage Board are: ( Note:
You must
have already linked your email address to a yahoo id to enable
access. )
(1) To access the Files Section of our Yahoo!Group for Report
Builder and
Crystal Reports and other 'goodies', please goto:
http://groups.yahoo.com/group/vantage/files/.
<http://groups.yahoo.com/group/vantage/files/.>
(2) To search through old msg's goto:
http://groups.yahoo.com/group/vantage/messages
<http://groups.yahoo.com/group/vantage/messages>
(3) To view links to Vendors that provide Vantage services
goto:
http://groups.yahoo.com/group/vantage/links
<http://groups.yahoo.com/group/vantage/links>
Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service.
[Non-text portions of this message have been removed]
Yahoo! Groups Sponsor
ADVERTISEMENT
<http://rd.yahoo.com/M=241773.2861422.4212389.1925585/D=egroupweb/S=1705
0071
83:HM/A=1394046/R=0/*http://www.hgtv.com/hgtv/pac_ctnt/text/0,,HGTV_3936
_580
2,FF.html> HGTV Dream Home Giveaway
<http://us.adserver.yahoo.com/l?M=241773.2861422.4212389.1925585/D=egrou
pmai
l/S=:HM/A=1394046/rand=188020319>
Useful links for the Yahoo!Groups Vantage Board are: ( Note:
You must have
already linked your email address to a yahoo id to enable
access. )
(1) To access the Files Section of our Yahoo!Group for Report
Builder and
Crystal Reports and other 'goodies', please goto:
http://groups.yahoo.com/group/vantage/files/.
<http://groups.yahoo.com/group/vantage/files/.>
(2) To search through old msg's goto:
http://groups.yahoo.com/group/vantage/messages
<http://groups.yahoo.com/group/vantage/messages>
(3) To view links to Vendors that provide Vantage services goto:
http://groups.yahoo.com/group/vantage/links
<http://groups.yahoo.com/group/vantage/links>
Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service
<http://docs.yahoo.com/info/terms/> .
[Non-text portions of this message have been removed]
Yahoo! Groups Sponsor
ADVERTISEMENT
HGTV Dream Home Giveaway
<http://rd.yahoo.com/M=241773.2861420.4212388.1925585/D=egroupweb/S=1705
007183:HM/A=1394045/R=0/*http://www.hgtv.com/hgtv/pac_ctnt/text/0,,HGTV_
3936_5802,FF.html>
<http://us.adserver.yahoo.com/l?M=241773.2861420.4212388.1925585/D=egrou
pmail/S=:HM/A=1394045/rand=337861649>
Useful links for the Yahoo!Groups Vantage Board are: ( Note:
You must have already linked your email address to a yahoo id to enable
access. )
(1) To access the Files Section of our Yahoo!Group for Report
Builder and Crystal Reports and other 'goodies', please goto:
http://groups.yahoo.com/group/vantage/files/.
(2) To search through old msg's goto:
http://groups.yahoo.com/group/vantage/messages
(3) To view links to Vendors that provide Vantage services goto:
http://groups.yahoo.com/group/vantage/links
Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service <http://docs.yahoo.com/info/terms/> .
[Non-text portions of this message have been removed]
________________________________________________________________________
________________________________________________________________________
Message: 4
Date: Thu, 23 Jan 2003 14:35:00 -0800
From: Thad Jacobs <tjacobs@...>
Subject: RE: Time Out / Shutdown utilities can corrupt Vantage d ata.
I'm saying don't use any time-out utility on a workstation that transacts
with the progress database, unless you are willing to accept the risk of
having issues such as troy has experienced, unless you know that that
utility will gracefully close out vantage and back out all pending
transactions.
-----Original Message-----
From: Winter, Patrick [mailto:pjw@...]
Sent: Thursday, January 23, 2003 2:32 PM
To: 'vantage@yahoogroups.com'
Subject: RE: [Vantage] Time Out / Shutdown utilities can corrupt Vantage d
ata.
Are you tell us not to use the Progress Time Out Utility?
Patrick Winter
-----Original Message-----
From: Thad Jacobs [mailto:tjacobs@...]
Sent: Thursday, January 23, 2003 4:18 PM
To: 'vantage@yahoogroups.com'
Subject: [Vantage] Time Out / Shutdown utilities can corrupt Vantage data.
Just to reiterate a key point, and at the risk of sounding redundant, if
anyone is using a time out utility, or any program that performs a hard
shut-down of vantage or the client machine it is running on, they run the
likely risk of transactions being halted midstream.
Of course, one of the inherent flaws of the classic client-server
architecture is that when business logic is running on the client side is
that an application relies heavily on the client workstation for
transactional integrity. I look forward to Sonoma, which will have all the
business logic running on the server.
Until we're on Sonoma, though, I'd strongly recommend that we all suspend
the use of time-out and auto-shutdown utilities on data-entry workstations,
or at least only use programs that will gracefully shutdown vantage and back
out any open transactions (if there are such programs). I imagine that past
use of such utilities are likely to continue to create anomalies that
unnecessarily eat up both ours and Epicor's time.
Yes, you can tell users not to leave transactions open when they leave their
desks, but staking referential integrity entirely on a user's organic memory
is not best course of action. When it gets down to it, the database is
running on our clock, not theirs, and though we can' t prevent them from
making typos, the problems generated when vantage is forced to crash in the
middle of a transaction fall completely within our jurisdiction as DB
Administrators.
One may wonder why Epicor hasn't built into vantage a timeout function.
Yes, it would end up detracting slightly from their licensing revenue.
However, they have created the feature that disallows multiple open
instances per workstation, which shows me that they are open to implementing
features that save customers licensing costs, because customer satisfaction
is key to their survival.
By putting in a time-out utility, Epicor would be designing a feature into
their program that hinders user productivity and moral. How would you like
it if you were typing an important e-mail, left for lunch, and came back
only to find that Outlook had crashed because your boss doesn't want to buy
sufficient CAL's for exchange? How likely would you be to recommend
Outlook/Exchange to colleagues?
All our employers are making a huge investment in client licenses for
vantage, because there is a consensus that Vantage user licenses are worth
the money wey pay for them. Yes, A time-out utility may be of great use on
pc's on which we can absolutely guarantee no transactions originate from
(assuming no user productivity is lost due repeatedly having to log back on)
On data entry workstations, though, it is a corner cut that is already
resulting in data corruption and nearly untraceable descrepancies vantage
databases.
Thaddeus Jacobs
IT Developer
Kinematic Automation, Inc.
mailto:tjacobs@... <mailto:tjacobs@...>
-----Original Message-----
From: Troy Funte [mailto:tfunte@...]
Sent: Thursday, January 23, 2003 11:15 AM
To: vantage@yahoogroups.com
Subject: Re: [Vantage] Inventory Not Updating Correctly
Update on this issue:
We were able to replicate a situation with the Timeout Utility (Mike's)
that leaves an orphaned record in PartTran. Here's how I reproduced the
problem.
1. Enter the Receipt from Manufacturing screen, and select a job to "Receive
from Inventory".. Enter a Qty of 1 or more.
2. Now let the Timeout Utility kill the Vantage session (in your test
database, of course).
The result: In PartTran for the part, there will be a MFG-STK transaction
with the Qty entered, but the OnHandQty will not be updated by the orphaned
transaction. In addition, the job header does not record that the product
was received. This in turn makes it so that you cannot 'unreceive' the part
because you will get an error saying that no parts were received in the
first place. Running the Stock Status report for any past date will cause
it to see the transaction and calculate it, thus corrupting the Stock Status
report by the same amount.
My advice for Timeout Utility users is to alert your users to this possible
dangerous scenario and make sure they don't leave transactions partially
transacted when leaving their desk for any reason. I'm not sure if this
affects any other screens in Vantage, although we have had AP groups that
wouldn't post after the Timeout Utility left them hanging.
I believe there are still other possible issues with the Stock Status report
for past dates and possibly with OnHandQty's, but this is the main one for
us it appears.
Troy Funte
Liberty Electronics
----- Original Message -----
From: Troy Funte
To: vantage@yahoogroups.com
Sent: Monday, January 20, 2003 10:43 PM
Subject: Re: [Vantage] Inventory Not Updating Correctly
Good Questions, Lydia.
* I honestly don't know what impact having transaction dates back to
1969 would do. Obviously, Vantage would think you had some inventory back
on 1/1/1970 for a 1969 transaction. I don't think you can run the report
for further back than that.
* As far as the Inventory VALUES... if you've ever done a cycle count,
then your inventory in Vantage will be correct from that date forward... at
least until this 'bug' happens again. Also, you would be in the predicament
that, should you ever need to run the 'fixbinsall.r' to program, it would
sort of 'undo' what your cycle count did for those parts that may have been
affected by this in the past.
* I've checked past and future dates in our system, and there are none
that I can see. I used a crystal report to check the whole PartTran table
for any TranDate that was greater than TODAY or less than 1/1/1970.
* Lastly, in our case, the fixbinsall.r program (after running it on a
test database) cleans up the stock status completely. Running it on
1/1/1970 it says: Zero. I page of empty warehouses. If dates were an issue
for us, the fixbinsall.r would not have cleaned those up. In your case, the
old and new date problems could be clouding the issue quite a bit. I have a
Crystal report for Vantage 5.1 that will check to see what the Calculated
OnHandQty SHOULD be, and compares it to the current PartBin.OnHandQty. It
will show me if they are not equal -- which highlights the problem we are
discussing here.
I hope that made sense and clarifies things for you.
Troy Funte
Liberty Electronics
----- Original Message -----
From: Lydia Coffman
To: vantage@yahoogroups.com
Sent: Monday, January 20, 2003 6:55 PM
Subject: RE: [Vantage] Inventory Not Updating Correctly
I'm at a loss here -- if I run the stock status in the "way back"
machine, I
get 37 items that show up before Vantage was ever installed. However,
our
status and Inventory VALUES on the current report is correct -- I've
checked
them against our cycle count inventory that was completed today. We
have
never had a stk-mtl transaction that didn't work--but the dates aren't
always in your view. Try setting the date on Part tracker AHEAD a year,
or
even ten years.
Also, I am positive that there are transactions in my database(packing
slips
and invoices at least) that are dated 1989 and 1969 and 2010--we had a
very
bad combo of person making packing slips with the wrong date and invoice
clerk not double checking. That could account for quite a few errors in
the
6 years that we've had Vantage. Also, all but 2 of our items that
appear on
the "way back" are manufactured, not purchased. Maybe you had someone
receiving items with the wrong date at some point. Maybe you should
give a
look at packing slip tracker and see if you have packing slips dated
"way
back".
Vantage 5.1
Lydia
Canyon Engineering Products
lcoffman@...
----- Original Message -----
From: "Troy Funte" <tfunte@...>
To: <vantage@yahoogroups.com>
Sent: Friday, January 17, 2003 9:27 PM
Subject: Re: [Vantage] Inventory Not Updating Correctly
> We have had the very same SERIOUS issue. In fact, I have an open
issue
on this with Epicor now. We had the same problem in
Vantage 3.0 and 5.0, we are now seeing it in 5.1 as well. It has
caused
major problems with the integrity of our Inventory. I
still don't think Epicor knows how this happens exactly, although as you
have discovered, it seems to be pinpointed to STK-MTL
transactions not adjusting the OnHandQty correctly. You mention
purchased
parts only, but we have seen it with manufactured parts
as well (both subassemblies and top level parts, which tells me that it
may
not be limited to the STK-MTL transaction type).
> For us the problem was serious enough that we had a meeting with
Epicor
on it over a year ago -- partly to say, "if you know of
a problem like this, you should at least let user's know so that they
can
watch their inventory closer. And if we're having this
problem, other users are probably having it as well". They have not
acted
on that suggestion to date. (This suggestion was to
higher Epicor management, not Tech Support, by the way).
>
> I HAVE DISCOVED HOW TO SEE IF THIS PROBLEM EXISTS IN YOUR DATABASE BY
RUNNING A TEST YOUR STOCK STATUS REPORT. AFTER YOU TRY
THIS PROCEDURE, I WOULD BE LIKE TO HEAR FROM EVERYONE ON THE LIST WHO
FINDS
THIS PROBLEM -- IT CAN BE *VERY SERIOUS* FROM A
MATERIALS AND ACCOUNTING STANDPOINT.
>
> HERE'S WHAT YOU DO. Run the Stock Status report... but instead of
using
TODAY'S date, enter a date in the past that is far enough
back to precede your earliest transaction in your database. It may take
some
time to run. 1/1/1970 is a good date since it is
probably old enough to precede any installation of Vantage. Also, I'm
not
sure what logic Vantage uses for Date schemes, but if you
enter a date like 1/1/50, it may give you 2050 instead of 1950. Running
the
Stock Status for 1/1/70 should give you a ZERO dollar
Stock Status report with ZERO parts in stock. If you find ANY parts
listed
(positive or negative), note the part(s) and I'll bet
you a candy bar that your OnHandQty is wrong for that part(s). The
reason
this logic works is this: To find the OnHandQty for dates
prior to today, the Stock Status assumes the current OnHandQty is
correct
TODAY, and then it goes through each transaction
(PartTran) for a Part and subtracts/adds the quantity of that
transaction to
the current OnHandQty until it reaches the date you
entered. It calculates backwards from today. Thus, back in 1970 (at
least
from Vantage's perspective) the OnHandQty for every part
should be ZERO. Now you can use the list of parts from the report to
calculate the TRUE (calculated) OnHandQty. After you have
printed/written the list of parts, open up PartTracker. Find one of the
guilty parts that has the shortest transaction history.
Next, go line by line through each transaction and manually calculate
what
the OnHandQty should be. If your transacton history is
less that 50 transactions, you can do a quick check by scrolling to the
end
(bottom) of the transaction history to see if the first
running total is correct. (I say less than 50 transactions because
there is
still a known issue with the running totals being
inaccurate after more than 100 transactions. The issue used to involve
anything over 50 transactions, so I don't trust either).
>
> Epicor sent us a fix program (fixbinsall.r) back last year to
recalculate
all the OnHandQty's. The problem was, after it fixed
our OnHandQty's, our Stock Status changed by significant $$ dollars.
Additionally, any parts that were previously affected by this
bug, and which also had a Cylce Count done on them to correct the
OnHandQty
through a ADJ-QTY, these parts are now OFF again by the
amount of the ADJ-QTY. So even after running the 'fixbinsall.r'
program, we
weren't sure if our OnHandQty was right or not. We
ended up doing a complete Inventory Count on all 10,000+ parts in our
inventory to clarify the integrity our Stock Status. And now
to find out that the problem is still there is incredibly disconcerting.
In
these days of Enron scandals, this type of thing makes
our Controller VERY nervous and our auditors VERY suspicious. Auditor:
"Why
did your stock status change by thousands of dollars,
but we don't see it in your Cost of Sales or anywhere else for that
matter?"
Controller: "Well, we ran this fix program on our
database and it changed our stock status, but you won't see any
transactions
showing that it did so." Auditor: "What did the fix
program do?'". Controller: "It adjusted for a bug in the database t<br/><br/>(Message over 64 KB, truncated)