Receiving EDI Data

This document will discuss the technical aspect of the receive function.

Before attempting to process incoming transaction sets, the system checks to see if:

  1. The EDI System Information record has been created.
  2. There is EDI data to be processed either from the input files to use for the range of file locations specified, and/or the transaction set holder file.
  3. A program directory, which is used to store incoming formulas, can be created.


If any of these conditions are not true, you will receive an error message, the system will not process incoming transaction sets, and you will be returned to the menu.

When processing incoming transaction sets from the transaction set holder file, the system will ensure that the transaction set holder is not in use (i.e. locked). If it is, then you will receive an error message, and you will not be allowed to processing incoming transaction sets from the transaction set holder file.

When processing incoming transaction sets from the range of file locations specified, the system checks to see if:

  1. The input directory is not in use (i.e. locked) for the file location being processed.
  2. The backup directory to use for this file location, as defined by the EDI File Location Maintenance function, has been created.


If any of these conditions are not true, you will receive an error message, and the system will not process the incoming EDI data from the file location being processed. Otherwise, it will "lock" the input directory of the file location that is being processed. As a result, only one user at a time can process incoming transaction sets for a given file location.

When processing incoming transaction sets from the input files specified for the range of file locations entered, the system assumes that each transaction set line in the input file is on a separate line (i.e., is unwrapped). If you are using a UNIX-based system, use the unwrap.sh shell script, located in the edi directory and supplied with the EDI system, to unwrap the input file. If you are using an MS-DOS (i.e. MS-DOS, OS/2, Windows 95, Windows NT) based system, use the unwrap.bat batch file, located in the edi directory and supplied with the EDI system, to unwrap the input file. Otherwise, check to see if the Value Added Network (VAN) you are dealing with can unwrap the data. If they are unable to do this for you, then please contact MXP support.

Trading Partner, Version and Transaction Set Information

Using the sender's and receiver's code in the GS (functional group header) segment of an incoming transaction set, the system looks for a trading partner on file where the functional group partner equals the sender's code, and the functional group's user ID equals the receiver's code. The functional group partner and user ID are entered in the GS section of the EDI Partner Maintenance function.

If the system cannot determine the trading partner to use by the sender's and receiver's code in the GS segment, will try to find the trading partner to use with the sender's and receiver's code in the ISA (interchange envelope header) segment of an incoming transaction set. In this case, the system looks for a trading partner on file where the interchange envelope partner equals the sender's code, and the interchange envelope's user ID equals the receiver's code from the ISA segment. The interchange envelope partner and user ID are entered in the ISA section of the EDI Partner Maintenance function.

If the cannot determine the trading partner to use by the sender's and receiver's code in the ISA segment, the system will try to determine the trading partner using the sender's and receiver's code from both the ISA and GS segments.

If the system is unable to determine the trading partner to use, then an error message will be displayed, and the transaction set will not be processed.

The version, and version suffix used by this transaction set are also determined from the GS segment.

If you are dealing with trading partners that use TDCC version numbers in the GS segment (e.g., X1/1), set up a translation table called EDIVERS using the EDI Translation Table Maintenance function, to translate the TDCC version to the appropriate ANSI X.12 version. For example, if TDCC version X1/1 corresponds to ANSI X.12 version 002001, you would set up a record using the EDI Translation Table Maintenance function for table code "EDIVERS" with a "From" value of X1/1, and a "To" value of 002001.

The transaction set to use comes from the ST (transaction set header) segment.

Once the trading partner, version and transaction set are known, the system checks to see if the transaction set information has been set up for this trading partner and transaction set. If it hasn't been set up, or the trading partner is not allowed to receive this document, then you will receive an error message, and the transaction set will not be processed.

The system also checks to see if you have set up the information required to assign data from incoming transaction set lines to the document that you are creating (i.e. a "transaction set map"). You will receive an error message if this has not been done, and the transaction set will not be processed.

If the system has determined that it has all the information that it requires to process an incoming transaction set, then it loads the transaction set into the system, and attempts to process it.

Assigning Values From an Incoming Transaction Set

For each transaction set that can be processed, the system creates the appropriate type of document, depending on the transaction set being used.

Using the transaction set map you have set up for the trading partner, version, and transaction set being processed in the Segment Override Maintenance function, the system assigns the incoming data elements to the database fields specified. A data element can be assigned to more than one database field by creating multiple line numbers for a given segment and position.

If the database field to be used when assigning a data element no longer exists, you will receive an error message and the document will not be created.

If you are assigning a data element to a database field that has extents (i.e., is an array), it will assign the data element to the array element specified. If the array element specified is larger than the number of elements allowed for the field, or you have entered 0 in the array element field, the system will increment the array index, so that the next available array element is used for that field. If you exceed the number of array elements allowed for the database field that you are assigning the data element to, you will receive a warning message, and the data element will not be assigned.

If an incoming formula is entered for a data element to be assigned to a database field, then the data element is modified using the formula entered before it is assigned to the database field. The incoming formula must result in a character value.

If the incoming formula hasn't already been generated using the Generate EDI Formulas function, then it will be generated as necessary. If there is a problem modifying the data element using the incoming formula, then the data element will be reset to its original value. For more information on entering formulas, please refer to the documentation for the Segment Maintenance and Segment Override Maintenance function, as well as the Entering EDI Formulas document in the Overview section.

If a translation table is to be used on the data element being assigned, then the system will convert the data element using the translation table entered. If there is no corresponding record in the translation table to be used, then the data element will be left unchanged. Otherwise, the data element is converted to the corresponding value. It should be noted that a data element is converted using the translation table specified after it has been modified using the incoming formula.

The system then checks to see if the data element to be assigned is valid for the database field to which it is to be assigned (i.e., is the proper data type). If it isn't, then an error message is displayed, and the data element is not assigned to the database field. The system also verifies if the field will fit in the format (size) allowed by the database field to which the database is to be assigned. If it isn't, then it will be truncated accordingly and a warning message will be displayed.

The system then assigns the data element to the database field specified. If the "Add/Assign" switch in the transaction set map is set to "yes", then the data element will be added to the database field. Otherwise, the data element will overwrite the contents of the database field. The "Add/Assign" switch only works if you are assigning data elements to character, integer, or decimal database fields. Data elements assigned to logical and date database fields overwrite the database field that they are being assigned to.

Qualifiers

If you are dealing with a transaction set line where multiple qualifiers can be sent by a trading partner, you will have to set up multiple line numbers in your transaction set map, each with the value of the qualifier that you are expecting. If the data element being processed matches the value of the qualifier on a given line in the transaction set map, then the subsequent field will be assigned to the database field using that line number.

If the qualifier is not found, then the subsequent field is not assigned to the database field, unless a "*DE*" qualifier has been used on a transaction set map for the data element. If the latter is the case, then the qualifier's description will appended to the data element being assigned to a database field.

To help clarify this, please consider the following:

An incoming transaction set contains the following transaction set lines ("*" is being used as the element delimiter):

REF*DP*DEPTNO
REF*JB*JOBNO

We would like to assign the "DEPTNO" data element to an order's department field, and "JOBNO" to an order's job number.

To do this, the transaction set map would be created as follows:

Segment Pos. Line Qualifier File Name Field Name
REF 1 50 DP
REF 1 51 JB
REF 2 50 order department
REF 2 51 order job-no

When the system processes data element 1 in the REF segment, it compares the qualifier entered for the line in the transaction set map to the data element. When it determines that qualifier "DP" is on line 50 of the transaction set map, the system automatically knows to use line 50 when assigning the subsequent value (i.e. the "DEPTNO") to the order's department field. If the system determines that qualifier "JB" is used on line 51 of the transaction set map, the system uses that same line number to assign "JOBNO" to order's job number field.

Now, let's say that qualifier "IL" comes in at data element 1 in the REF segment. Since we were not expecting the "IL" qualifier to be sent by the trading partner, then the subsequent field would not be assigned to a database field.

It should be noted that when the N1 and ATH segments are processed, the qualifier found in the first element of the segment is used for the entire transaction set line.

Validating Transaction Sets

After the system has finished processing the transaction set, and has assigned all the data elements to the database fields you have specified in your transaction set map, the system then proceeds to validate the document that has been created.

Wherever possible, the system provides defaults to fields if values have not been assigned to them.

In order to ensure database integrity, the system validates fields against the appropriate "master" files to make sure that they are valid.

If there are no problems with the documents that have been created, then the system assigns identification numbers (i.e., order numbers, voucher numbers) to the document, updates the necessary files, and leaves them in the system to be processed by other functions. Otherwise, the system does not create the documents.

If multiple documents are created from a single transaction set, then all the documents to be created by the transaction set must not have any errors in them. Otherwise, no documents will be created from this transaction set.

Documents created using the Receive EDI Data function can be processed using the appropriate entry function (i.e., Quotation Entry, Order Entry, Payables Entry, etc.), as though they were entered into the system manually. The difference is that the document's "Source-edi" switch is set to "yes". This allows you to identify those documents which came into the system using the Receive EDI Data function.

Test Mode

If a given document is marked as being a "test" document (this is defined in the ISA (Interchange Control Header) segment used for a transaction set), then it cannot be converted into an actual document. The document is validated, however, to ensure that it can be processed. If there are no errors in a transaction set that is in "test mode", a message displays indicating that the test document had no errors. NOTE: When an 850 is marked as being a "test" document and the front end parameter simulation is set to no the document will be placed in the holder file.

Transaction Set Holder

If a transaction set being processed has errors in it, the system stores the transaction set in the transaction set holder file. If input files are being processed, then the transaction set is assigned a transaction set identification number, which is displayed on the report.

If a transaction set with errors in it is being processed from the transaction set holder file, then statistics are updated, including how many times the transaction set has been processed, as well as the date, time, and user who last processed this transaction set. If the system is unable to update this statistical information, then a warning message is displayed.

If there are no errors in a transaction set, and the transaction set holder file is being processed, then the system automatically removes the transaction set from the transaction set holder file. This is true whether or not the transaction set is in "test mode".

If the system is unable to determine the trading partner, transaction set or version used, then the transaction set is not saved in the transaction set holder file when transaction sets are processed from an input file for a given file location. If this situation occurs frequently, you may want to load the transaction set into the transaction set holder file using the Load EDI Data function before attempting to process it.

Simulation Mode

The Receive EDI Data function can also be run in Simulation mode. If Simulation mode is selected, then documents are not created, transaction sets are not stored in the transaction set holder file, backup copies of the input file are not made, and the message "Simulation" is printed on each page of the report. If there are no errors in a given transaction set when a simulation is done, a message displays to indicate this fact.


Acknowledgements

Once the input files and/or the transaction set holder file are processed, the system automatically generates acknowledgements for the transaction sets that have been processed. In addition to the transaction sets that are processed, the system also generates acknowledgements which have not been marked as "sent".

If the system is unable to generate an acknowledgement for a particular transaction set, the Regenerate EDI Acknowledgements function can be run at any time to resend the acknowledgements in question.

If acknowledgements are generated, the system will then run the EDI Data File Transfer function and transfer the generated acknowledgements for each file location where a communications script has been specified, and the communications script is executed automatically. Please refer to that function's documentation for more information.

Transaction Set Considerations

The following should be considered when processing incoming transaction sets:

850 Transaction Set

When an 850 (i.e. Purchase Order) transaction set is processed, the trading partner's parameters listed below are used:

Generate Quotes (Y)/Orders (N):

Enter "yes" to generate quotations from an incoming purchase order, or "no" to generate orders from the purchase order.

Mult. items on SDQ quote/order:

Enter "yes" to allow multiple items make up an order if SDQ segments are sent in a purchase order, or "no" to have each item have its own order or quote number for each different customer specified on the SDQ segment.

Check Gross Prices:

Enter "yes" to have the system check the gross price assigned to a quote or order line against the system price, or "no" if you do not want the system to perform price checking.

If the gross price is not assigned, the system will default the price to the system price. If there is a discrepancy between the system price and the gross price assigned to a quote or order line, and this parameter is set to "yes", then a warning message will be issued. It should be noted that the quote or order will still be valid.

When developing a transaction set map to process incoming purchase orders, you must use lines 1 through 49 to assign data elements to quote and quote-line fields, and lines 50 through 99 to assign data elements to order and order-line fields.

The EDI entity used on the EDI document record will be the EDI controlling entity of the entity code entered in the transaction set information section for the 855 transaction set of the trading partner used. If the entity code is left blank, then the system will use the EDI controlling entity that you are logged onto when the Receive EDI Data function is run.

EDI document records created for purchase order acknowledgment can be reviewed and modified using the EDI Document Review function.

Purchase order acknowledgements are generated when the Generate EDI Data function is run. The system will use the information from the 850 transaction set that was received to create the purchase order acknowledgement for this purchase order.

875 Transaction Set

When an 875 (i.e. Grocery Purchase Order) transaction set is processed, the trading partner's parameters listed below are used:

Check Gross Prices:

Enter "yes" to have the system check the gross price assigned to an order line against the system price, or "no" if you do not want the system to perform price checking.

If the gross price is not assigned, the system will default the price to the system price. If there is a discrepancy between the system price and the gross price assigned to an order line, and this parameter is set to "yes", then a warning message will be issued. It should be noted that the order will still be valid.

If the incoming purchase order is not a "test" document, and you are not processing EDI Data in simulation mode, then the system will check to see if you are sending purchase order acknowledgements (i.e. the 855 transaction set) to the trading partner being used by this transaction set.

If you are sending purchase order acknowledgements to a trading partner, the system will save the incoming transaction set in the database, and will create an EDI document record for the purchase order acknowledgement.

The EDI entity used on the EDI document record will be the EDI controlling entity of the entity code entered in the transaction set information section for the 855 transaction set of the trading partner used. If the entity code is left blank, then the system will use the EDI controlling entity that you are logged onto when the Receive EDI Data function is run.

EDI document records created for purchase order acknowledgment can be reviewed and modified using the EDI Document Review function.

Purchase order acknowledgements are generated when the Generate EDI Data function is run. The system will use the information from the 850 transaction set that was received to create the purchase order acknowledgement for this purchase order.

810 Transaction Set

When an 810 (i.e. Invoice) transaction set is processed, the trading partner's parameters listed below are used:

Use exchange rate on CUR seg.:

Enter "yes" to use the exchange rate found on the "CUR" segment in an incoming invoice when an A/P voucher is generated, or "no" to have the system calculate the proper exchange rate.

820/823 Transaction Sets

The system will not convert the 820 (Payment Remittance) or 823 (Lockbox) transaction sets directly into system documents. Instead, the system will place the transaction sets into a suspended payments. The Edit Suspended Payments and Suspended Payments List functions can then be used to review the remittance and lockbox payments received via EDI.

After the suspended payments have been reviewed, they can be converted into cash receipts in the A/R system using the Convert Suspended Payments function if the A/R module is installed.

When processing lockbox transaction sets, a suspended payment record will be created for each payment remittance segment sent. When payment remittance transaction sets, a suspended payment record will be created for each ENT segment processed.

The system will default the entity and G/L codes for a suspended payment from the A/R and G/L control files.

If you have not specified the customer number to use, the system will attempt to determine which customer to use based on the reference (invoice) numbers that will be paid by this payment.

The system assumes that all reference (invoice) numbers specified for a particular payment are paid by the same customer.

When processing payment remittances, the system will create a stand-alone reference for any adjustments that are not linked to a payment.

864 Transaction Set

If a text message exists with the same partner, transaction set, GS control number, and ST control number as the transaction set being processed, then the transaction set being processed overwrites the existing text message.

If the maximum length of a data element in the transaction set is over 70 characters, then multiple text message lines will be created if necessary.

The system automatically deletes any text message lines that are blank.

997 Transaction Set

If a trading partner does not send the "AK2" segment as part of the functional acknowledgement, the system will acknowledge documents at the functional group level. Otherwise, the documents will be acknowledged at the transaction set level.

The system does not acknowledge documents that have already been acknowledged.

If the document itself was rejected by the trading partner the document is put in the holder file and the tset-is-no is assign in the EDI  document Review screen (EDI-4-1). You can then execute option EDI 5 - 4 (997 Data on Hold Report) Which will produce a formatted report showing the error(s) associated with the document.

Documents will be acknowledged even if the functional acknowledgement transaction set is sent in "test mode".

Backups

When the system has completed processing an input file for a given file location, it makes a backup in the backup directory specified for each file processed within each file location. The system uses a file name in the following format:

i-<date>.<num> (e.g., i-931011.002)

The <date> is the system date in "YYMMDD" format, and <num> is a three-digit sequential number. If the system is unable to make a backup copy, an error message displays.

After the system has completed processing an input file, the user receives a report indicating the status of the transaction sets processed. The name of the backup file is also printed on the report.

System Issues

When the system processes incoming transaction sets from a range of file locations, it creates a "lock" file in the input directory for the file location being processed. When the transaction set holder is processed, it is also "locked" to ensure that only one user can process incoming data from the transaction set holder at a time. In the event of a system crash, or other hardware failure, these "lock" files may not be removed. Use the Remove EDI Lock Files function to remove these "lock" files from the system.

While the Receive EDI Data function is running, the system creates documents in the database temporarily, in order to assign data elements from an incoming transaction set to the database fields specified in the transaction set map. If the documents have no errors in them, they are assigned the appropriate identification number (i.e. order number, voucher number, etc.). Otherwise, the documents are removed from the system. In the event of a system crash, or other hardware failure, the documents may not be removed properly, potentially causing a loss in database integrity. Use the Remove Orphan EDI Documents function to remove these documents from the system.

The system creates a directory underneath your working directory, called erp<terminalid>, where <terminalid> is the terminal from which this function is being run, to store generated incoming formulas which were not previously generated by the Generate EDI Formulas function. If a system crash, or hardware failure occurs, this directory may not be removed by the system. You will have to exit to the operating system, and remove this directory, along with any subdirectories manually.

Last updated October 20, 2006