Electronic Data Interchange

It seems ironic that the promise of electronic transmission of transactions from one company's system to suppliers and customers is not really fulfilled in my experience. Often large customer insist on smaller manufacturers enabling themselves for EDI at great expense using a "VAN " - intermediary to convert the message from the customers format to one the small manufacturer can process. The VAN charges per transaction plus a monthly subscription. The benefits are not really acheived for the smaller manufacturer it simply adds cost.

To me the real beauty of EDI would be if no VAN was required. This is why my effort has been to create the complete EANCOM standard messages. The difficulty with electonic transaction standards is that they are enormous and a huge coding effort is required to create a complete implementation. The focus of webERP has been on creation of electronic invoices for customers and also the receiving of orders from customers.

The aim is to automate the process for creating a sales order in webERP as far as possible to maximise the benefits of EDI - otherwise an EDI message is possibly not even as good as a fax or email order. I am 60-70% through creating a reader for EANCOM 2002 - based largely as a subset of EDIFACT D96A.

I currently only have INVOIC creating messages. the table


contains the format of the ORDERS message as per EANCOM 2002.

Also I am some way along creating a script called EDIProcessOrders.php (this script is in the distribution) which reads the format of ORDERS message and parses all incoming EDI Orders in the incoming directory. It attempts to cover the entire standard ORDERS message from the EANCOM standard. It is not complete although way more than 50%.

I have written up some notes in the manual extracted here for the benefit of interested persons:

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:

* EDI reference that they are identified by
* Transport mechanism and address to which the invoice/credit note messages are to be sent - either email as a file attachment or via ftp (file transfer protocol)

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


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 EDIProcessOrders.php 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 webERP 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 webERP 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 webERP 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.

EDI sending of invoices is further advanced that receiving orders. However, much of the infrastructure is there and I am looking to work with a client
who wants this functionality to make it sing for them.

I am imagining incoming edi messages via email attachements or scheduled pick up from an ftp server. - into the EDI_Incoming and a cron or scheduled job under windows. processing these into sales orders. Actually getting the email attachment off the email and into the EDI_Incoming directory will need additional code or scripting and is not covered in the software - the process in webERP is to take the flat files in the EDI_Incoming directory (this directory is modifiable) and converting them to webERP orders as though manually keyed.

I have used the EANCOM subset of UN/EDIFACT standard for the format of messages - due to the potential size of these messages there is quite a bit of code and I suspect a whole lot of redundant code. But I need to keep it in conformance with the standard and as generic as possible. The thinking is to make EDI a more practical and workable solution for smaller businesses.

As I said EDI is not solid and tested yet and I need a site to work with to get it working.
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki