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 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 defined program will be executed in batch under the job name "ECSEDIMAP", a job will be submitted for each transaction to be mapped to the user files. The batch job will be submitted using the default ECS/EDI Job Description "ECSEDI", this should be reviewed and if changes are necessary then this job description (ECSEDI) should be copied to "ECSEDIMAP" and the jobd attributes (such as job queue and library list) amended dependant on the environment requirements.
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 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 defined program will be executed in batch under the job name "ECSEDIMAP", a job will be submitted for each transaction to be mapped to the user files. The batch job will be submitted using the default ECS/EDI Job Description "ECSEDI", this should be reviewed and if changes are necessary then this job description (ECSEDI) should be copied to "ECSEDIMAP" and the jobd attributes (such as job queue and library list) amended dependant on the environment requirements.
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\ Note: It is recommended that Input, Output, Processed and Error folders are created as sub-folders within a main "EDI" Folder for the purpose of Interchange data back up and disaster recovery purposes.
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\ . Note: It is recommended that Input, Output, Processed and Error folders are created as sub-folders within a main "EDI" Folder for the purpose of Interchange data back up and disaster recovery purposes.
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\ . Note: It is recommended that Input, Output, Processed and Error folders are created as sub-folders within a main "EDI" Folder for the purpose of Interchange data back up and disaster recovery purposes.
Enter a free format Application TP Id, up to 50 characters can be entered. The Application Trading Partner Id is used for reference for purposes only, it 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 application Trading Partner Id is used for reference purposes for both Inbound & Outbound Events . Updates database field IEXE.XETPA.
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 Functional Acknowledgement Required check box is used to indicate whether a functional acknowledgment is expected to be returned for this Inbound Event. Checking and unchecking this box will toggle the value 1 or 0 in the field IEXE.XEFA. Custom developed Functional Acknowledgement generation and conversion programs are required to fully utilise this functionality.
The Block Duplicate Inbound Interchange check box is used to control whether inbound interchanges can be unpacked more than once. If this box is checked then the Interchange header values are analysed during the inbound interchange unpack process and if it matches a previously unpacked interchange then the interchange unpack is aborted. A warning email message will be sent to the Event administrator when an interchange is blocked. Checking and unchecking this box will toggle the value 1 or 0 in the field IEXE.XEIDUP. It is recommended that this check box is configured consistently for all Events relating to the same Trading Partner.
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 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. The Interchange Envelope Values must be configured to match what is expected on the inbound interchange. By default the Message Envelope selection data is populated with the EDI Message Id.
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 will be executed within the server job by default, Trigger programs can be submitted to Batch rather than executed within the server job by creating a job description called "IE800JD" in a library within the standard ECS/ie library list. The ECS/EDI Processor will check for the existence of a *JOBD called "IE800JD" within the library list. If this Job description exists then the job is submitted to batch using this job description.
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 trigger program will be executed within the server job by default, Trigger programs can be submitted to Batch rather than executed within the server job by creating a job description called "IE800JD" in a library within the standard ECS/ie library list. The ECS/EDI Processor will check for the existence of a *JOBD called "IE800JD" within the library list. If this Job description exists then the job is submitted to batch using this job description.
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: It is recommended that Input, Output, Processed and Error folders are created as sub-folders within a main "EDI" Folder for the purpose of Interchange data back up and disaster recovery purposes.
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\ . Note: It is recommended that Input, Output, Processed and Error folders are created as sub-folders within a main "EDI" Folder for the purpose of Interchange data back up and disaster recovery purposes.
Enter a free format Application TP Id, up to 50 characters can be entered. The Application Trading Partner Id is used for reference for purposes only, it 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 application Trading Partner Id is used for reference purposes for both Inbound & Outbound Events . Updates database field IEXE.XETPA.
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 Max Msgs in Interchange entry allows you to define a maximum number of messages that may be packed into an outbound interchange. If only one message per interchange is required then this entry should contain a value of 1. The default and maximum permitted value is 999999.
The Functional Acknowledgement Required check box is used to indicate whether a functional acknowledgment is expected to be returned for this Outbound Event. Checking and unchecking this box will toggle the value 1 or 0 in the field IEXE.XEFA. Custom developed Functional Acknowledgement generation and conversion programs are required to fully utilise this functionality.
The Check Box Consolidate Messages with other Events relating to this Trading Partner controls whether messages generated under this Event Id can be consolidated with messages with messages from other Events Id's into the same interchange.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. In order for messages to be consolidated, the Traading Partner value must equal the same value for each of the Event Id's and the Consolidate Message flag must be enabled for all of the linked Event Id's.
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:
Note: It is recommended that Input, Output, Processed and Error folders are created as sub-folders within an "EDI" Folder for the purpose of Interchange data back up and disaster recovery purposes.
<<<<< 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.
