The level of control required will depend on the criticality of the
documents being exchanged and the tolerance of the endusers for ambiguity.
It also depends on your confidence in your EDI solution as implemented.
Below I have listed some of the tools and messages that may be used to
verify application to application communications.
Verify message was received by VAN and picked up by recipient:
VAN Reports
Verify message was received by recipient's translator:
997 Functional Acknowledgment
EDI translator reports
Verify message was received by application:
850 Purchase Order 855 Purchase Order
Acknowledgment
869 Order Status Inquiry 870 Order Status Report
860 Purchase Order Change Request - Buyer Initiated 865 Purchase
Order Change Acknowledgment/Request - Seller Initiated
820 Payment Order/Remittance Advice 824 Application Advice
831
Application Control Totals
940 Warehouse Shipping Order 945 Warehouse Shipping Advice
Application Activity reports
Some sites desire another level of control such as the EDI translator
received 53 POs and the Order Entry system loaded 53 POs. Others want to
know that the checksum of a file sent from one internal system matches the
checksum of the file received by another internal system, e.g. EDI
translator to mainframe.
All of this requires custom programs to parse the pertinent reports, extract
data from audit trails, and query the application database and create
summary reports or notify users of exceptions. No standard methodology
exists. Best practices depend on your industry and tolerance for pain.
Some sites monitor everything manually. I recommend and attempt to design
and implement lights out environments which means doing the custom
programming required to reconcile all transactions. This does not have to
be done all at once but can implemented gradually.
Most of the enterprise level EDI packages have become robust enough that
they contain the tools required to implement a high level of control. The
link between the translator and the application will have to be implemented
through the use of confirming documents assuming your application supports
them or custom programming.
Jim Divoky
EC Solutions
2304 North Ridge Drive
Jefferson City, TN 37760-5320
Providing SAP EDI/EC Consulting and Contracting
Home 865-471-5529 TN
Office 330-678-6091 OH
Mobile 330-606-6826
Pager 877-282-3426 tollfree
Email [EMAIL PROTECTED]
To send email to mobile phone, use "Phonemail" as subject.
160 chars text only.
Web Page http://jim.divoky.home.att.net
----- Original Message -----
From: Debbie Shaver <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, May 02, 2000 7:02 PM
Subject: EDI System Design Question
> Hi all,
>
> I'm new to this list, and new to EDI. Our company has begun several
> initiatives to implement traditional EDI transactions with customers,
> suppliers, and distribution channels. As a result, we decided it would be
a
> good idea to develop an infrastructure group for all those common tasks
> needed to administer EDI. We have the GENTRAN product installed with some
> customized data flows going in and out. (This was the result of an EDI
> pilot last year that was put on hold for business reasons).
>
> Coming from a mainframe background, one of the key principles drilled into
> my head was, when you send data from one system to another, you ALWAYS
> implement some kind of control totals/audit procedures to make sure all
the
> data got there correctly. I have searched all over, including this list's
> archives, for some white paper describing industry best-practices on the
> "control points" within the traditional EDI transaction life cycle. How
do
> I make sure ALL the invoices our suppliers sent to our VAN actually make
it
> into our AP system, and how do I make sure ALL the payment transactions
> actually make it to the bank? I understand FAs (997s) can be used to
> indicate the transaction made it to the "receiving" translator, but how
do
> I make sure it gets into the receiving business application?? How do I
make
> sure the custom code that moves the data from the GENTRAN output into the
> business application doesn't have a coding mistake in it that might cause
> records to be dropped/inserted incorrectly??
>
> There seem to be 6-10 "touch points" as a transaction goes from the
> originating business application, through the translator, to the van, into
> the receiving translator and finally into the receiving business
> application. Outside of the 997 reconciliation, what would you guys
> recommend as "best practices"?? If you had it to do over, what kind of
> auditing checkpoints would you put in place??
>
> Thanks in advance!!
> Debbie Shaver
> [EMAIL PROTECTED]
> 206.318.8739
>
> =======================================================================
> 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/
=======================================================================
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/
