Inbound Invoices:
The sender must verify the invoices made it to your VAN mailbox. Once there
you can now track them based on my comments in my previous response.
Outbound Payment Advices:
The bank should send a confirming 824, Application Advice, which you can
compare with your 820. Ideally, you can do this programmatically which will
eliminate any manual intervention except when there is problems. I have
done this by saving the outbound 820 and performing a line-by-line match
with the inbound 824 using a UNIX script. Exceptions are emailed to the
accounts payable person or sent to an network monitoring system or
application inbox.
Jim Divoky
----- Original Message -----
From: Bob Scheuermann <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, May 03, 2000 8:34 AM
Subject: Re: EDI System Design Question
> All:
>
> I read and reread Debbie's question re controls and believe she is asking
> for methods to check if the data from her EDI system was accurately and
> completely passed into her internal application system for invoicing. She
> has an issue of tracking the data between the EDI system and the
> application.
> While the 824 could be used for the EFT tracking, she still needs a method
> to track if a transmission was lost, ie: 10 820's sent to bank, 10 820's
> noted on the returned FA and 9 processed by bank for payment.
> That's my take on it.
>
>
> Bob Scheuermann
> EDI Analyst
> The Mentholatum Co.
> 716-677-2500 ext. 1519
>
> -----Original Message-----
> From: Michael Pokraka
[mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 03, 2000 5:24 AM
> To: [EMAIL PROTECTED]
> Subject: Re: EDI System Design Question
>
> 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/
>
> =======================================================================
> 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/