Mark, I think your answer is correct is from a translator neutral
standpoint, however, specifically regarding Gentran NT, (and making the
assumption that the trading partner sends back a 997 that acks each received
ST-SE),
All you have to do is create a scheduled event to export the outbound
transactions status report . I think the function is "report" or something,
it's in the dropdown list box -
The file produced is a table of each transaction and information about it.
One of the codes tells you the status of the transaction; one of the status
codes stands for "Ack Overdue". (I think you can even set the time frame in
which an ack is considered to be overdue.)
Then you want to produce a report of only the overdue records. As I said, we
did this in MS SQL server, but I could also whip up a filter in perl that
would accomplish the same task more efficiently.
So, I wanted to point out that Gentran NT already does this ack tracking by
default as part of the product, you simply have to do a little scripting and
scheduling to take advantage of it.
Another point to note is that you will find out if a particular transaction
within an interchange was unacked or rejected, which is also important
beyone just asking "did my file get there?"
Anthony Beecher
-----Original Message-----
From: Mark Kusiak [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 30, 2001 1:52 PM
To: [EMAIL PROTECTED]
Subject: Re: Gentran questions
Robyn,
As to question 1, you can automate the process of passing back the EDI
information
with the appropriate transaction number and the EDI IC# and GC# with the
times that
the information was transmitted to the trading partner. This does require
that
programming be accomplished to allow for the system to track outbound
transactions
against the FA to close the loop. At the point where the outbound
transaction is
generated, write a record to a table or file keyed by the transaction
number.
This process can be accomplished by determining the files that are used to
update the
history within the translator itself or modifying the jobs that process the
history such
that the information is captured. Look at the documentation for your
translator to
determine how the history update process is accomplished. Most of the afore
mentioned
information is captured in a file somewhere either permanently or on a
temporary basis.
The file format or layout should be in the documentation. If not, then get
it from the
vendor.
The programming requires that you look at the file for items that are not
transmitted as a check
to see if the transaction got out, and acknowledged for those that did. It
provides a
full proof way to close the loop and make the process exception driven
instead of a full
blown manual reconciliation each day. It takes some time to build the
process, but will save you
countless hours. Four years ago, we did the manual audit each day and it
took one person
about 3.5 hours each day to check it and ensure that the transactions that
were supposed to
get out did. Our audit technique was error prone to say the least as no one
person audited
in the same manner. We now are able to reconcile using the automation in
about ten minutes.
The cost benefit is that in a year, the number of hours used to reconcile
each 24 hour
period for the year is 1044 hours. The time needed to check with automatic
audit in place
would be at approximately 44 hours for the whole year. That's a difference
of 1000 hours at
the basic labor rate of whatever. Assume $50.00 per hour with fringe, (the
going rate in LA)
and that's a savings of about $50K a year. This assumption is that the
reconciliation is
accomplished 5 times per week Monday through Friday using an average of 4
hours per day. If you
do it more then five times a week, then add the appropriate times for each
method to the base
provided above. This also does not take into account the savings in float
for the unbilled
orders or other such productivity losses.
This provides you with tools to ensure that the audit control is in place to
track the outbound
data from your system. Without them, you are subject to a manual
reconciliation to ensure that
everything that was supposed to go, went.
Mark
-----Original Message-----
From: Robyn Noble [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 30, 2001 9:06 AM
To: [EMAIL PROTECTED]
Subject: Gentran questions
Hi Everybody!
I have a couple of quick Gentran questions that I am hoping
someone can help me with:
We currently are using Gentran Server for Windows NT running on
Windows 98 for EDI and we have an AS400 that everything else is
on.
1) Any suggestions on how to check to make sure that for
outbound files everything that comes out of the AS400 makes it
all the way out to the VAN? Currently it is a manual and very
time consuming process where two different reports are
run...one from the AS400 and one from Gentran and a person has
to go through each making sure counts match. I know how
checks were done at my previous company but am hoping someone
here has a better solution.
2) Right now Gentran is running extremely slow, even just to
look up trading partner information and translating even one
document is painfully slow. I am working with someone from
Gentran to figure out what the problem is but was hoping
someone else on the list experienced this and could give me a
quick fix. This has been this way for a very long time.
There is only one computer that doesn't have this problem and
the only difference is that Windows NT is running on it not
Windows 98. I was told that is not the problem. Any/all
suggestions would be GREATLY appreciated.
I know this isn't the most exciting topic but this list has
without a doubt been one of the best resources I've ever had!
Have a great day!!
Robyn Noble
New Balance Athletic Shoe, Inc.
ECommerce Project Leader
Phone: 617-746-2509
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
