Hiya,
Perhaps it's not so much the design, but rather the philosophy behind EDI
that's a bit different to what you're used to.
The difference here is that there is a point where the _responsibility_ gets
transferred (similar to incoterms in trading).
This is generally agreed upon within an industry. The critical point is that
once the doc is with your partner, it's _their_ responsibility to get it
into their system or let you know if there's a problem. On the legal side,
this should be similarly covered in your EDI trade agreements.
Cheers
Michael Pokraka
SAP EDI Analyst
Samsung Semiconductor Europe Ltd
Please note new telephone numbers as per the UK number change
(<http://www.numberchange.org/>)
Tel: +44 (0)20 8380-7050
Fax: +44 (0)20 8380-7218
The information contained in this e-mail may be privileged, confidential and
protected from disclosure. If you think this email has been received in
error please notify the following address:
<mailto:'[EMAIL PROTECTED]'>.
This message transmitted on 100% recycled electrons.
-----Original Message-----
From: Debbie Shaver [mailto:[EMAIL PROTECTED]]
Sent: 03 May 2000 00:03
To: [EMAIL PROTECTED]
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/
