38 - EDI

EDI stands for electronic data interchange - the electronic transmission of transaction information between trading partners. There are numerous standards for the encoding of such transactions the most widely used being UN/EDIFACT and its derivative EANCOM implementation. In fact many industry groups use the standard formats in slightly different ways and some businesses within the industry use the industry standard slightly differently again. So ultimately, the standards are really only a framework for what the actual messages look like. In implementing EDI in KwaMoja, some flexibility in the format of messages to be sent and received is available. EDI messages are created in flat files in the directory specified in config.php for EDI outgoing messages and a log of the EDI messages sent is retained also. The messages can be sent either as an email attachment to the customer supplied email address or via ftp to a customer supplied ftp server address - using the ftp username and password provided by the customer.

EDI Setup

To enable EDI transactions for a customer, first select the customer from the Select Customer link on any page, then click the link - Customer EDI Configuration. This page allows selection of the type of transactions that are to transmitted electronically currently only invoices/credit notes and orders are available. Each must be specifically enabled to activate them. Each customer must have their:

If the transport mechanism is to be ftp - this must be compiled into PHP with the flag -enable-ftp, most windows PHP installtions have this by default now. Additional fields for the ftp server username and password will also be required.

To activate EDI polling for invoices to send the script EDISendInvoices.php must be run as a scheduled job - using cron or some other scheduling system -see automating sales reports. It can also be run from the utilites menu Z_index.php with debugging output.

To activate EDI polling for orders to be entered as received the script ???? must be run as a scheduled job using cron or some other scheduling system.

Sending EDI Invoices

EDI messages are made up of segments which must appear in a certain order. Since customers will require EDI invoices in slightly different formats, the exact format can be defined in the table EDIMessageFormat. This table has a record for each customer invoice line and the sequence when it must appear in the message. The field line text in this table can include any of the predefined EDI invoice variables surrounded by "[" and "]" to denote them as a variable to be replaced with the appropriate value as follows:

EDI Invoice Detail Section
EDITransNo The unique EDI transaction number
InvOrCrd Whether the transaction is an invoice or a credit - the value of this variable is an EANCOM defined number, 388 for a tax invoice and 381 for a credit note
TransNo The transaction number of invoice or credit
OrigOrDup Whether the transaction is a duplicate or original sending the value of this variable is an EANCOM defined number 7 for a duplicate and 9 for an original
TranDate The transaction date in the format CCYYMMDD
OrderNo The original order number - only for invoices
CustBranchCode The customer's internal code for the branch
CompanyEDIReference The customer's EDI reference code
BranchName The branch name
TaxAuthorityRef The businesses Tax Authority reference number
DatePaymentDue The due date for this transaction
TaxTotal The total amount of tax on the transaction
EDI Invoice Detail Section - for the lines on the transaction
StockID The KwaMoja item code
CustStockID The customer's internal code for the item
QtyInvoiced Quantity invoiced or credited
LineTotalExclTax The total for the line excluding tax
UnitPrice Unit price for the item
LineTaxAmount The tax applicable to the line
EDI Invoice Summary Section
NoLines The total number of lines on the invoice/credit
TotalAmountExclTax Total amount of the transaction excluding tax
TotalAmountInclTax Total amount of the transaction including tax
NoSegments The total number of segments in the transaction this is required as a control check in the summary

There is therefore great flexibility in how the messages are defined. The variables for the summary and heading sections can be used in any section. The detail section variables can only be used in the detail section.

Most customers will require that the branch to which the invoiced goods are delivered to, be identified using the customer's coding system. It is therefore important to ensure that the customer's branch code is actually entered against the KwaMoja branch record. The variable CustBranchCode is retrieved from the branch record and if it is not entered then the EDI transaction will fail.

Some customers may also require the item code to be their item code, not the KwaMoja item code. The variable CustStockID is derived from the cross reference table EDIItemMapping which would need to contain a cross reference record for each item that they may buy.

The script that creates the EDI invoices (EDISendInvoices.php) should be run automatically in the background as a scheduled task. It first gets a list of all customers who should receive EDI invoices (or credit notes) - as determined in the settings of their DebtorsMaster record. Then the script goes through each customer returned in turn to get any invoices or credits that have not already been sent. A flat file is created for all the customers invoices and credits and sent to the customer using the transport, address and other parameters defined in the customer edi setup page - recorded against their DebtorsMaster record. There is a link to enable the script to be run manually - the browser will also show the output of the EDI message.