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