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/

Reply via email to