Tricks when debugging an EDI transaction

Sometimes you might need to debug some EDI transactions and the lack of CR/LF can be an issue. I found out that Notepad++ can easly fix this issue:

But that's just the tip of the iceberg! I have developed a bunch of macros that can be used in a wide range of scenarios and that's a small sample: due to some internal procedures, I needed to remove the goods description into BAPLIE file but did not have the chance to edit related mapping rule. Goods description is stored in Segment Group 5 as FTX04:

FTX+AAA+++FAK OR CARGO  NOS WITH REFERENCE 998740013'

Applying the following criteria, in conjunction with CR/LF, will purge unwanted information and will change segment as follow: 

FTX+AAA+++'

                                    

Hope these tricks will be useful to you!

Mapping a remark field into FTX segment

Mapping an internal remark field, from the source data base to a FTX segment of an out-coming EDI transaction, may be  an issue.

First of all you should wonder which kind of data the end user could store into the source data base as remark and if it is appropriate to send it to an external customer: while debugging some EDI transactions it happened me to find very funny data and even some telephone numbers to contact, at the transport stage of the container, in case of problems. 

Furthermore, piece of data into FTX segment, are often incompatible with the character set adopted in the interchange and, although unnecessary, prevent message to be properly processed. 

Here below some very common errors which happen in my EDI environment mainly based on the UNOA character set:

Lowercase characters

FTX+AAI+++clean container foodstuff quality'

Missing escape character "?" in conjunction with ":"

FTX+AAI+++RELEASE DATE FROM: 19/09/2012'  

 Not allowed character "\"

FTX+AAI+++CLEAN CONTAINER \ FOODSTUFF QUALITY'

Adding CR/LF to an EDIFACT message

Everybody who handles EDIFACT messages, at least once in his life, needs to have a closer look at the message/segment contents in order to figure out the reason of a mapping failure: well, it's a dirty job but someone got to do it...

Then things may get harder when message has no CR/LF breaks and your EDIFACT translator has not a built in tool  to make message readable: find out the error becomes a real nightmare !

Well, a reader of  this blog (off course smart people read smart blog :D) has created a web application with the following features: 

1. Adding a CR/LF after every segment ends;
2. Properly numerate every line/segment of the message. 

You can have a look at this new brand project here and maybe, in the future, the developer will also add some extra features, who knows... :)

I have also added the site in the Web Utilities section.

Thank you Nick for sharing your good job !