About Inbound Transactions
Several functions occur in EDI that allow the inbound data to flow seamlessly from both customers or vendors into SyteLine. These processes include:
- Loading translated data into the EDI database tables from the flat files
- Validating EDI data
- Posting inbound data from the EDI tables to the normal SyteLine tables
- Processing errors
- Creating error reports
- Purging inbound transactions
Accessing the EDI mailbox initiates an inbound data flow. This action drives data through the translator into the EDI tables in SyteLine.
The following diagram illustrates the inbound functions of EDI.
Demand Side Inbound Transactions
The EDI interface supports these inbound transactions from your customers:
- Purchase Orders (850/ORDERS): When posted to SyteLine, these transactions create or update regular or blanket customer orders.
- Planning Orders (830/DELFOR): When posted to SyteLine, these transactions create or update blanket customer order lines (forecasts of a customer's order) or blanket releases.
- Shipping Orders (862/DELJIT): When posted to SyteLine, these transactions create or update blanket customer order lines (confirmations of a customer's order) or blanket releases.
The system loads transactions from the translator as formatted ASCII files.
Supply Side Inbound Transactions
The EDI interface supports the following inbound transactions from your vendors:
- Purchase Order Acknowledgments (855/ORDRSP): This transaction posts to SyteLine as an EDI purchase order acknowledgment. AutoPost is available.
- Advance Ship Notice (856/DESADV): This transaction posts to SyteLine as an EDI vendor ship notice, and may be used as input to the PO Receiving function.
- Invoices (810/INVOIC): This transaction posts to SyteLine as an EDI vendor invoice, and may be used as input to the process of generating A/P Vouchers. AutoPost is available.
Loading Inbound Transactions
You can import EDI inbound transactions using the EDI Transaction Load Routine utility, or the system can load the inbound transactions as part of a background task you define.
SyteLine loads the flat ASCII files output by the translator into the EDI database tables. Multiple lines in the ASCII file and multiple records in the EDI tables represent a single transaction. Minimal data validation occurs during this phase of the inbound process.
The files are named as listed below, where the XXX suffix for datafiles corresponds to the Trading Partner code from the EDI Parameters form (both supply and demand), and the HHMM.JJJ indicates the time and Julian date for the archive file.
This table describes the file names for each inbound transaction type:
| Trans Type | Data Dir Filename | Archive Dir Filename |
|---|---|---|
| 810 | 810_DTL.XXX | INV(HHMM.JJJ) |
| 830 (Header) | RSEQ_HDR.XXX | RH(HHMM.JJJ) |
| 830 (Detail) | RSEQ_DTL.XXX | RD(HHMM.JJJ) |
| 850 | 850_EXP.XXX | PO(HHMM.JJJ) |
| 855 | 855_DTL.XXX | ACK(HHMM.JJJ) |
| 856 | 856_DTL.XXX | VSN(HHMM.JJJ) |
| 862 (Header) | RSEQ_HDR.XXX | SH(HHMM.JJJ) |
| 862 (Detail) | RSEQ_DTL.XXX | SD(HHMM.JJJ) |
Validating Transactions
EDI validates inbound transactions according to a predefined set of rules for each transaction type. The two types of validation rules are interface errors and data errors.
Interface errors result from a conflict in the setup between the translator and SyteLine. Data errors are errors in the content of the data.
The inbound posting process validates each incoming transaction. If the transaction passes the validation, it proceeds to the posting process. The system identifies transactions that fail the validation process. For demand-side transactions, you can view errors on the EDI Customer Orders form by selecting . For supply-side transactions, each transaction has a corresponding report which you can run to review errors.
Posting Transactions to the ERP
To post inbound transactions to SyteLine automatically, set the Auto-Post flag for the Trading Partner to Inbound or Both. When loading transactions into the EDI tables, the system checks this option to determine if it should post the transactions automatically. Posting moves the data from the EDI tables to the normal SyteLine database tables.
The system validates all incoming transactions and posts to the system all transactions that have no errors. The program identifies any transactions that do not post because of an error and stores them in the EDI tables to be processed using the appropriate form.
If you set the Auto-Post flag to None, the system loads the transactions into the EDI tables with no further processing. You can then run reports to review the data before attempting to post the transactions into SyteLine normal database tables.
Processing Errors
For demand-side transactions, you can update the field on the screen when an inbound data field contains an error. This allows the transaction to be posted to SyteLine, but you must communicate this change to the trading partner. Some trading partners choose to delete the original transaction and retransmit it with the data corrected. Other trading partners require a Purchase Order Acknowledgment (855/ORDRSP), indicating the changes you have made to their order.
You can override some errors found in inbound data by turning off some of the validation for that trading partner. Examples of such errors include "Credit Limit Exceeded" or "Incorrect Unit Price."
For supply-side transactions (information is coming to you from your vendors), you cannot change data before posting. When errors occur, you can either override them in the SyteLine system itself or request that the data be retransmitted to you.
See Errors That Stop Demand EDI CO Transaction Postingand Errors That Stop Supply EDI Transaction Posting.
Online Error Log and Error Reports
Error reports are available for each incoming transaction. These reports start the validation process on the transaction and report all errors found in the transaction.
The reports include summary information for transactions with and without errors. You can print all error reports for a range of trading partners. Additional selection criteria are available for each specific transaction type.