DYNAMIC 3i ELECTRONIC DATA INTERCHANGE (EDI)

Basic Steps and Flow

EDI (Electronic Data Interchange).

In short instead of a customer calling up your order desk and requesting quantities of product they create and send an electronic list. They require that you confirm/communicate back to them acceptance of their electronic list. When shipping of the order is done a shipping document is sent electronically and the invoice as well. They may even send you payment electronically.

EDI could be handled totally by email and basically adhere to the definition of Electronic Data Interchange. There are however, a multitude of transactions sets and segments that define and say what an order is, what an invoice is etc.

These definitions or transaction sets are controlled by a universal set of rules drawn up by a standards committee (ANSI). Since there many different software programs that handle distribution in there own way, these standards assure that at least at the EDI stage all customers and vendors talk the same language. These standards are somewhat cryptic but map out a set of transactions that are universally used and understood.

Dynamic3i will handle inbound orders and outbound confirmations and invoicing.

As mention above this inbound/outbound processing is cryptic:

Inbound purchase orders are known as:              850’s      PO           850
Outbound functional acknowledgements are:    997’s      ACK        997
Outbound shipping confirmations are:                    856’s      ASN        856
Outbound order invoices are (credit/debit):        810’s      INV          810

The inbound 850 is a Purchase Order (PO) and the transaction set is known by the EDI standards as an 850 transaction set. In short a PO 850 is an electronic version of an 8.5 X 11 piece of paper that a business customer used to fill out and send to their vendor with information on it as to what they would like to order and where they would like it delivered.

The outbound 997 is a Functional Acknowledgement (ACK) / confirmation that the electronic purchase order was received, validated and is being processed into an order. Similar to an email read confirmation that is sent back from a recipient stating that the email was opened and looked at.

The outbound 856 is an Advance Shipping Notice (ASN) / confirmation of the goods shipped and the location shipped to. The ASN 856 is an electronic version of the packing slip, which will physically accompany the shipment.

The outbound 810 is an Invoice. These invoice 810’s are electronic versions of the paper bill that is normally sent to the customer. They can be either credit or debit invoices.

Main setup (Dynamic3i – Software)

To start using the EDI module within Dynamic3i there is some setup. The most important part is to define to the system your electronic data trading partners (customers). This is done by using the ‘Trading Partner Maintenance’ (EI0100).

This defines to the system a lot of cryptic information that is used behind the scenes to handle all those inbound/outbound transactions for customers and vendors with whom you will be dealing with via EDI. This will tell the software the different types of communication and the Trading partner and ID code to expect from the mapper's input or output. The input and output records are individually identified using the Group Control number (another cryptic EDI identifier)

Within Dynamic3i the trading partner is set up separately from the actual customer or vendor. The trading partner id is then attached to the Customer Master -(GB0900) or the Vendor Master – (GB1000) to make the relationship complete.

Once the trading partner is defined and attached to the customer/vendor then the Dynamic3i software has a central repository for how to treat the processing of the distribution cycle for that customer electronically.

Inbound

Inbound PO 850’s (Purchase Orders) consist of cryptic BEG and PO1 pairs as well as many other segments, translated these are loosely equivalent to Dynamic3i’s Order header (BEG) and Order Detail (PO1) and are created into Orders using EDI Order Generation – EI0400.

Step 1.

Inbound EDI transactions are presented to Dynamic3i as a flat file located somewhere on the Network (Note. File must have an extension eg. ‘.dat’ or ‘.txt’). Within the EDI module under processing the import EDI File application (EI0300) is used import this file into Dynamic3i. This simply loads and validates an electronic file to be in a certain format (see 850 EDI PO Upload File Format below). If the file is not then an error report is generated identifying the error and the transactions are written to an error file (so that this file may be fixed and then re run).

The file must then be fixed externally from Dynamic3i and re-loaded via EI0300.

For trading partners that are setup to receive acknowledgements (ACK 997) an outbound transaction file is created (see 997 Transaction format below) with an acknowledgement transaction for the customer. This is done for each valid PO 850 set received. (Discussed in outbound section below)

Upon successful load the first stage of the EDI step is complete. Dynamic3i now has an EDI set of PO850 records loaded and ready for processing.

Step 2.

Processing of these records is done by way of EDI Order Generation (EI0400). This application runs through the records loaded in step 1 for the trading partner range entered and validates them according to Dynamic3i as if the PO were being entered within the purchasing module. Eg. Is the customer number valid, ship to customer valid, country valid, product code valid etc. All transactions that pass validation (Both BEG and PO1 pairs ie. the order has a valid header and some details) are created into Orders within the Order Entry module as if they were keyed in using Order Entry (OE2100).

Orders are created in the following sequence:

if the expected ship date > 6 weeks from the existing date, a future order will be created.
if none of the above validations are flagged, a normal order will be created.
If the order contains items that exist on a blanket order for the statement to customer then the blanket order has a blanket order release done for the required items/quantities.

Only 1 future order or 1 normal order is created with appropriate shipping data.

Transactions that are invalid are flagged and made available in the EDI Order Generation Maintenance table for correction. The transactions in error can be printed on a report either by them selves or included with ‘all’ other transactions based upon the selection of the ‘Print all/error transactions (A/E)’

Step 3.

Transactions within step 2 above that are invalid can be fixed by using EDI Order Generation Maintenance. Once fixed then they are made available the next time that step 2 is done. If they are not fixed they will continue to be flagged as invalid and show on the error report within step 2.

		M/O	Type	Start	Length	Value	Map850
HDR	Header Record	M
01	Record ID	M	ID	1	3	HDR
02	Doc Type Id	M	ID	4	3	850	ST01
03	Trading Partner	M	AN	7	15		ISA06
04	Functional ID	M	AN	22	2		GS01
05	Group Control			4	9		GS06
06	Version	M	AN	33	3		GS08a
07	Release	M	AN	36	9		GS08b
08	No of PO inc.	M	N	45	6		GE01
BEG	Beginning of PO	M
01	Record Id	M	ID	1	3	BEG
02	TS Purpose Code	M	ID	4	2		BEG01
03			PO	6	22		BEG03
04	PO Date	M	DT	28	6		BEG05
05	Shipment Method	O	ID	34	2		FOB01
06	Location Qual	O	ID	36	2		FOB02
07	Description	O	AN	38	80		FOB03
08	Sale Req.Code	O	ID	118	2		CSH01
09	Total Amt Ded.	O	N	120	9		ITA07
10	%Deducted Inv.	O	N	129	6		ITA09
11	Term Type Code	O	ID1	35	2		ITD01
12	Term Discount %	O	N	137	6		ITD03
13	Discount Days	O	N	143	3		ITD05
14	Net Days	O	N	146	3		ITD07
15	Cancel Date	O	DT	149	6		DTM02_001
16	Shpt must arr.	O	DT	155	6		DTM02_002
17	Date exp. Ship	M	DT	161	6		DTM02_010
18	Name	O	AN	167	35		N102
19	ID Code	M	AN	202	17		N104
20	Address1	O	AN	219	35		N301
21	Address2	O	AN	254	35		N302
22	City	O	AN	289	19		N401
23	Province	O	AN	308	2		N402
24	Postal Code	O	AN	310	9		N403
25	Dept ID	O	AN	319	15		REF02(DP)
26	Number of Line	M	N	334	6		CTT01
27	N104 Ult	O	AN	340	17
28	Contact Name	O	AN	357	40
29	Order Message	O	AN	397	120
30	Order Type	O	AN	517	1
31	Warehouse Number	O	AN	518	3
32	Order Date	O	DT	521	6		YYMMDD
33	Order Number	O	N	527	8
34	Special Label	O	AN	535	1		X or NULL
35	Shipping Method	O	AN	536	20
36	Bill-to Customer	O	AN	556	9
37	Ship-to Country	O	AN	565	40
38	Ship-to Phone	O	AN	605	30
39	Card Expiry Date	O	DT	635	6		YYMMDD
40	Card Number	O	AN	641	20
41	Card Name	O	AN	661	40
42	Payment Code	O	AN	701	2
43	Payment Amount	O	N	703	14		9(11).99
44	Card Start Date	O	DT	717	6
45	Salesperson Number	O	AN	723	6
46	Freight Amount	O	N	729	14		9(11).99
47	Card Issue No.	O	AN	743	6
48	Buffer field	O	AN	749	100
NTE	Notes	O
01	Record Id	M	ID	1	3	NTE
02	Free Form Msg	O	AN	4	60		NTE02
PO1	Baseline Item	M
01	Record Id	M	ID	1	3	PO1
02	PO line no	M	AN	4	6		PO101
03	Qty Ordered	M	N	10	9		PO102
04	Unit of Measure	O	AN	19	2		PO103
05	Price Per Unit	O	N	21	14		PO104
06	Vendor Product			35	30		PO107
07	Customer SKU	O	AN	65	30		PO109
08	Non std UOM	O	AN	95	30		PO111
09	Delivery Date	O	DT	125	6
10	Expected Ship Date	O	DT	131	6
11	Quantity per Box	O	N	137	6
12	Buffer Field	O	AN	143	100

Field	Name	M/O	Type	Start	Length	Value	EDI997
EDI Doc (01)	Header Record	M
01	Record ID	M	ID	1	7		EDIDOC
02	Sender ID	M	AN	8	12	GLBMST	ISA06
03	Version/Release	M	ID	20	10	850	GS08
04	Receiver ID	M	AN	30	12	850	ISA06
05	Control			42	19	Spaces
06	Version	M	AN	61	6	TRDMST	GS08A
07	Release	M	AN	67	6	TRDMST	GS08B
08	Message Type	M	AN	73	8	9..\97++
Detail	Detail Record (>1)	M
01	Record ID	M	AN	1	3	ACK
02	Functinal Group ID	M	ID	4	2	850	GS01 GS01 AK101
03	Group Control			6	9	850	GS06 GS06 AK102
04	Number of TS Included	M	NO	15	6	850	GE01 GE01 AK902

Outbound

Once the EDI Orders are created into Dynamic3i they are processed in the same manner as if the order was keyed into Order Entry – (OE2100).

The acknowledgment (ACK 997) is produced in step 1 above. If the customer, via the trading partner ID is setup to receive these then the transaction file is created at the same time that a valid PO 850 transaction set is loaded using the import EDI File application (EI0300). It simply confirms to the sending customer that the electronic Purchase Order was received and is being processed. The ACK 997 EDI formatted transaction file is produced on the std. EDI directory defined in Dynamic3i’s Global Master Maintenance – GB0100. It is named ‘EI0300’ followed by a seven-digit system generated number and contains acknowledgements for valid loaded EDI transactions only. This file is then presented to an EDI provider’s mapper, which maps the records contained in it to a std X12 formatted 997 Edi transaction that is sent to the sending customer via the provider.

The next step in the Order Entry Distribution cycle is shipping confirmation. If the customer is setup via the trading partner id to receive electronic advance shipping notices (ASN 856’s) then when a shipment is confirmed via Shipping Confirmation – OE2400 an EDI ASN 856 Formatted file is created in the database. These shipping notices (ASN 856’s) are then processed by running the Send EDI Ship Notice – EI0600 application. This can be run or re-run for a range of trading partners and by shipping date. The EDI ASN 856 Formatted file is produced on the std. EDI directory as defined in the Global Master Maintenance – GB0100.

Errors and Error Handling (EDI – Inbound transaction files)

Import EDI File – EI0300

Errors can occur in the loading of the actual EDI file sent from the customer (EI0300) and in the order generation of that file (EI0400).

An error in HDR (Transaction Header) will hold the entire order (BEG and PO1’s). All other valid transactions (PO’s) will go thru to the SDC system.

The details of the electronic purchase order are validated only when the order is generated via EDI Order Generation – EI0400.

If errors occur in the load of the EDI file sent the BEG and PO1 pair sets are written to a new file with the same name and a ‘.err’ extension. The valid transactions are loaded and the whole sent file renamed to the same file name and a ‘.old’ extension.

Example. EDI file sent is EDIDec11 (10 transactions)

Errors occur on load to 5 transactions so a new file is created, EDIDec11.err that holds these five transactions.

The valid transactions are loaded and the file renamed to EDIDec11.old

In this case the ‘.old’ file can be archived or saved off. The ‘.err’ file can be fixed and then renamed to a new file to be loaded again eg. EDIDec11fixed, and the process is repeated.

Validation occurs on the following std. PO 850 Generic file as follows:

These errors are reported on the ‘EDI 850 HDR error report – EI0301’

HDR record (Order Header)

X12 Std.	Description	Validation
ST01	Document type	Must be ‘850’
ISA06	Trading Partner	Must be valid trading partner set up on Trading Partner Maintenance – EI0100 and have the ‘PO 850 Flag’ set
SA15	Test/Production	Must be ‘T’ or ‘P’ and match the setting for the load. Ie. EI0300 set to ‘P’ so EDI file data must be ‘P’ as well or an error is flagged - ‘Flag not matched to batch program’
GS06	Control #	If the trading partner setup on the system is set to have sequence control then this number must either be equal to the control number on the trading partner file or be greater then it.

(Other segments/values are at the mercy of the sender/mapper from which the file was sent)

EDI Order Generation – EI0400

An error in BEG (Order Header) or corresponding PO1 (Order Detail) will hold the entire order (BEG and PO1’s). All other valid PO’s will be processed into an order.

These errors are reported on the ‘EDI Order Generation Error Report – ‘EI0401’

(The ISA06 and GS06 segments are printed with the transaction for reference purposes.)

BEG record (Order Header)

X12 Std.	Description	Validation
BEG01	TS Purpose Code	Must be ‘00’ Original Order
FOB01	Shipment Method Payment	Must be ‘CC’ or ‘PP’ Only
FOB02	Location Qualifier	Must be ‘DE’ or ‘OR’ Only
ITA07	Total $ amount of deduction	Must be 0
ITA09	% deducted from Invoice	Must be 0

(Other segments/values are at the mercy of the trading partner from which the file was sent)

X12 Std.	Description	Validation
PO102	Qty ordered	Must be whole number (no decimals) If the item is Back Ordered, and the product does not allow back orders as defined in Product Master maintenance – IN0100 then record will be flagged as ‘Back order not allowed for this product’ on error report. If < 0 then record will be flagged as ‘No Quantity’ on error report. if division does not yield a whole number then record will be flagged as ‘Does not convert to whole number’ on error report.
PO104	Price per unit	list price must match list price of product. must have ordering unit of measure for bill to customer
PO107	Product Id	Must exist on stock file IN0200. Uses special names for product id in PO107 (if not null) to getvalue.
PO109	Cust. Product id	If null then sets itself to PO106 above.
N102	Name	See below.
N402	Province	If the name above is not null and this item is not null then this must be a valid province code setup on province file maintenance - GB1300 If this item is null then the postal code below (N403) is used to find a valid province via definition defined on postal code vs province translation OE0650.
N403	Postal Code	See above.
N104	Ship To Cust.	Must be a valid customer setup on the customer table - GB0900 (linked via the trading partner id and id code setup in trading partner maintenance - EI0100)
N104_bill	Bill To Cust.	Based upon the Ship to above ; The bill to customer is set To be the ‘ship to’ or it set to the ‘bill to’ of the ‘ship to’ as defined in the customer table - GB0900.
ITD03	Discount % (Bill to)	Based upon a valid Bill to customer these three items must match the terms code defaults for the terms code assigned to the bill to.
ITD05	Discount Days	See above
ITD07	Discount Net Days	See above

(Other segments/values are at the mercy of the sender/mapper from which the file was sent)