Debbie Shaver, of Starbucks, summarized "various solutions for control
totals/audit procedures within an EDI transaction life cycle." See
http://www.mail-archive.com/[email protected]/msg00872.html.
997 reconciliation is automatically handled by the Gentran translator,
and it will alert you to overdue 997s and rejected transaction sets. If
there are no FA exceptions reported by the translator, you can probably
safely assume that everything you sent out was received and readable (if
not necessarily acceptable - that's the purpose of application
acknowledgments).
I get the willies just even thinking about writing programs to read
Gentran's audit logs or reports, or even reading Gentran's database
files. Any of these might change on you with new releases, and it makes
a switch from Gentran to another vendor, or even newer versions of
Gentran, that much harder.
Controls to make sure everything coming from the back-end applications
made it into the translator, through the VAN, and to the trading
partner - validated with 997s - are reasonable. And conversely,
anything you pick up from the VAN should be acknowledged with a 997 and
passed to the applications. The translator probably has most of these
controls built-in.
When it comes to mechanically reading the VAN reports, there are the
same kind of problems as reading the translator audit logs. This reminds
me of the X12 242 Data Status Tracking Transaction Set which was
originally designed to track VAN interconnections for the VANs
themselves. It could also theoretically serve as a VAN report,
insulating you from changes in printed reports or having to
screen-scrape the VAN's web pages. The 242 could be used to reconcile
what Gentran knows it has sent or received with what the VAN thinks.
It's a clever idea, instigated by the Federal government to shield it
from the vagaries of each and every VAN's proprietary report format. But
I don't know of any VANs who actually support the 242, nor of any
translators which would be able to automatically integrate the 242 with
their audit reports.
And there's not necessarily a one-to-one relationship between messages.
Sure, the normal response from a customer to your 810 invoice might be
an 820 EDI payment (advice). But if your customers are anything like
me, you might receive multiple payments for the same invoice. Though an
Internet e-commerce millionaire, I sometimes find myself strapped for
cash, and to ward off the creditors I pay just a small part of what's
owed. It keeps them at bay for another month since they think I'm
making some effort, and something's always better than nothing.
Or you may never see an EDI payment at all! Instead, is your company
really going to complain because the customer cut a check and mailed or
walked it into the Accounts Receivable Department? In that case, you
(in the EDI department) will never know the payment was made, and
shouldn't care. I don't mean that you don't care in an abstract way -
but you've done what's expected of you. Presumably, your job is not to
dun the customers, it's just to inform the A/R department of remittances
which came from the bank or the payer via EDI. If A/R sees that a
payment was never made (they have they own ticklers, auditing and
balancing), they can have you send a duplicate invoice, if needed.
Anyway, 820 payments go to the payer's (originating) bank, not you,
since only banks can move funds, though the remittance advice may come
directly from the payer. But there's the possibility that the 820
remittance advice appears (on the ISA) to have come from the bank
instead of the payer, if the remittance and payment were bundled. This
would make reconciliation with a particular 810 invoice difficult since
all you have is the ISA sender address in the translator logs. Or you
may even see the payment, without ever having sent an invoice, in an
ERS, or pay-on-receipt, environment.
I think the same thing could happen with PO Acks: though an 855 PO Ack
is the normal response to a PO to accept the contract, not everyone
sends them. And if everyone doesn't send them, then that's just more
special logic and exception-handling for your auditing system. The EDI
system should just loyally feed the back-end applications, if
acknowledgments do come in. But It's up to the purchasing system to
worry about (application) acknowledgements. And who knows: maybe the
vendor had a question about an order that came in via EDI, called the
buyer directly, and resolved the problem over the phone. With a verbal
acceptance, the buyer might've updated the purchasing system herself.
And for all I know, maybe it's possible for a single PO Ack to
acknowledge multiple POs, throwing any attempt to match up 850s and 855s
further out of wack
EDI is message-centric - alternative or manual intervention may trigger
events or processes outside of the EDI system, perhaps making any
attempt to "balance" the messages a kludge.
Of course, I've been wrong before: has anyone successfully done this?
Inquiring minds want to know.
William J. Kammerer
FORESIGHT Corp.
4950 Blazer Memorial Pkwy.
Dublin, OH USA 43017-3305
(614) 791-1600
Visit FORESIGHT Corp. at http://www.foresightcorp.com/
"Commerce for a New World"
=======================================================================
To signoff the EDI-L list, mailto:[EMAIL PROTECTED]
To subscribe, mailto:[EMAIL PROTECTED]
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
