EDI Trading Partner Event Configuration
An EDI Trading Partner Event relates to a trading relationship linking a single Trading Partner and Business Transaction to form an Event. EDI Event Configuration is required to link a Trading Partner with a Transaction to configure the communications method, Source/Destination folders, communication/application identifiers, trigger programs, Event owner and Trading Partner information.
The set up and configuration of EDI Events is required before Inbound or Outbound EDI transactions can be processed using the ECS/EDI Processor integrated with ECS/integrated email.
To configure an EDI Event, perform the following:
Inbound EDI Trading Partner Event
The following describes the requirements of adding a definition for an Inbound EDI Trading Partner Event:
The ECS/EDI Processor can be configured to execute a Trigger Program following the successful validation and conversion of an inbound EDI transaction. The Trigger Program is a user developed AS/400 based program, not supplied with ECS/integrated email. The Trigger Program could reference an application mapping program designed to map the data from the ECS/EDI Transaction database to the Business Application system.
The ECS/EDI Processor can be configured to execute a Trigger Program on Error following the unsuccessful validation of an inbound EDI Transaction. The Trigger Program on Error is a user developed AS/400 based program designed for remedial action to be taken in the event of a failure.
The Input Folder must contain the full path details of where the ECS/EDI Processor retrieves the inbound EDI Interchanges from. This could be the same path that was used as the destination folder for Inbound e-folders if the EDI Interchange was received by email. Example of an Input Path path is: C:\EDI\IN\
The Error Folder must contain the full path details of where the ECS/EDI Processor places inbound EDI Interchanges if they fail the validation. Example of an Error Folder path is: C:\EDI\IN\ERROR\ .
The Processed Folder must contain the full path details of where the ECS/EDI Processor places inbound EDI Interchange files when they have been successfully processed. Example of a Processed Folder path is: C:\EDI\IN\PROCESSED\ .
Every
EDI Trading Partner Event should have an administrator that is
responsible for dealing with any errors caused while processing Inbound
EDI Transactions relating to this Event. All error reports will be
automatically emailed to the email address stored within the
Administrators email address entry and the emails will be sent
with the subject text entered in Error email subject text text
box.
The EDI Standard must be selected from the drop down list and should correspond to the format of the EDI Interchange the Trading Partner is sending. The ECS/EDI Processor supports the EDIFACT (Electronic Interchange For Administration Commerce and Transport) and any subsets.
The EDI Message must be selected from the drop down list and should correspond to the format of the EDI Message the Trading Partner is sending. If the Trading Partner is sending multiple message types then each message type (or transaction) must be defined as a new Trading Partner Event.
The Message Version must be selected from the drop down list and should correspond to the Version of the EDI Message the Trading Partner is sending. If the Trading Partner is sending multiple message types then each message type (or transaction) must be defined as a new Trading Partner Event.
The Syntax Set must be selected from the drop down list and should correspond to the format of the EDI Interchange the Trading Partner is sending. The ECS/EDI Processor supports Syntax Sets defined for use with the EDIFACT standard.
The Element Translation command button enables the maintenance of the element translation table relating to this EDI Trading Partner Event.
The
The Interchange and Message Envelope Value command buttons enables the configuration and maintenance of data used to link the Inbound EDI transaction to this Trading Partner Event. By default the Message Envelope selection data is populated with the EDI Message Id, further configuration is necessary if multiple transactions from different Trading Partner Events share the same Input Folder.
Cllick OK to validate the entries and add the Event or Cancel to return to the EDI Trading Partner Event list without updating the record.
The following window displays an example of a completed EDI record for Inbound processing:
Outbound EDI Trading Partner Event
The following describes the requirements of adding a definition for an Outbound EDI Trading Partner Event:
Enter a logical name as the EDI Event Id used to identify the Trading Partner Event. Up to 15 characters can be entered.
Enter an Event Description relating to the Business Transaction function and Trading Partner. A description of up to 50 Characters is allowed.
Select the EDI Event Direction , Inbound relates to transactions received from Trading Partners. Outbound related to transactions sent to Trading Partners.
Enter a free format Trading Partner Name, up to 50 characters can be entered. The Trading Partner Id can be used for descriptive purposes or for Trading Partner identification purposes when integrating to a business application. Such as, storing Customer/Supplier numbers. The Trading Partner is used by the ECS/EDI Processor to consolidate outbound Messages generated by different Events into the same interchange for transmission to the Trading Partner. If a Trading Partner value is entered that has already been assigned to another Outbound EDI Event then a warning that the Events will be linked will be displayed. This value can be retrieved by the ECS/EDI Processor during the packing for insertion within the Envelope Segments if the special value &TP is used.
The Sender Id and Receiver Id entries are designed to store unique Trading Partner communication or business application identifiers. These values can be retrieved by the ECS/EDI Processor during the packing for insertion within the Envelope Segments if the special values are used (Special Values: Sender Id=&SID and Receiver Id=&RID).
The ECS/EDI Processor can be configured to execute a Trigger Program following the successful creation and validation of an outbound EDI Message. The Trigger Program is a user developed AS/400 based program, not supplied with ECS/integrated email. The Trigger Program could reference an application mapping program designed to map the data from the ECS/EDI Transaction database to the Business Application system.
The ECS/EDI Processor can be configured to execute a Trigger Program on Error following the unsuccessful validation of an outbound EDI Message. The Trigger Program on Error is a user developed AS/400 based program designed for remedial action to be taken in the event of a failure.
The Output Folder must contain the full path details of where the ECS/EDI Processor places Outbound EDI Interchanges when they have been successfully processed. This path can be the same as the source folder used within Outbound e-folders if it is intended that the EDI Interchange is sent to the Trading Partner as an email attachment. Example of an Output Folder path is: C:\EDI\OUT\ . Note: the Path to the Folder must already exist or an error will occur.
The Error Folder must contain the full path details of where the ECS/EDI Processor places Outbound EDI Interchanges if they fail the EDI validation. Example of an Error Folder path is: C:\EDI\OUT\ERROR\ .
Every EDI Event should have an administrator that is responsible for dealing with any errors caused while processing Outbound EDI Messages relating to this Event. All error reports will be automatically emailed to the email address stored within the Administrators email address entry and the emails will be sent with the subject text entered in Error email subject text text box.
The EDI Standard must be selected from the drop down list and should correspond to the format of the EDI Interchange the Trading Partner is sending. The ECS/EDI Processor supports the EDIFACT (Electronic Interchange For Administration Commerce and Transport) and any subsets.
The EDI Message must be selected from the drop down list and should correspond to the format of the EDI Message the Trading Partner is sending. If the Trading Partner is sending multiple message types then each message type (or transaction) must be defined as a new Trading Partner Event.
The Message Version must be selected from the drop down list and should correspond to the Version of the EDI Message the Trading Partner is sending. If the Trading Partner is sending multiple message types then each message type (or transaction) must be defined as a new Trading Partner Event.
The Syntax Set must be selected from the drop down list and should correspond to the format of the EDI Interchange the Trading Partner is sending. The ECS/EDI Processor supports Syntax Sets defined for use with the EDIFACT standard.
The Fixed Format Record Length entry contains the record length of the EDI Interchange file created by the ECS/EDI Processor. The default value is 0, which will create a variable length Interchange file.
The Element Translation command button enables the maintenance of the element translation table relating to this EDI Trading Partner Event.
The Code List Tables command button enables the maintenance of User Code List Table Values relating to this EDI Trading Partner Event.
The Interchange, Functional Group and Message Envelope Value command buttons enables the configuration and maintenance of the Envelope Segments, inserted at the time the ECS/EDI Processor creates the Interchange. Default Envelope Segment values are automatically defined, which can be configured to meet the Trading Partners exact requirements.
Click OK to add the Trading Partner Event or Cancel to return to the EDI Event list without updating the record.
The following window displays an example of a completed EDI record for Outbound processing:
<<<<< Back to ECS/EDI Menu <<<<<
Copyright © 1998-2003 Electronic Commerce Solutions All rights reserved.
ECS/integrated email & ECS/ie are trademarks of Electronic Commerce Solutions, Ltd. Other brand names and product names used in this document are the trademarks and trade names of their respective holders and may be registered.
