Date/time in EDI message

An UN/EDIFACT message contains several references to date/time but, first of all, you will find date/time into the UNB segment as S004.0017  / S004.0019:

    UNB+UNOA:2+SENDER-ID+RECEIVER-ID+090730:1323+1'

This data/time identifies when the full interchange was generated and it's a good practice to use the UTC format. 

UTC date/time allows to determine exactly when the interchange was generated without converting local date/time of the sender into local date/time of the receiver. 

For instance: 

    UNB+UNOA:2+SENDER-ID+RECEIVER-ID+090730:1323+1'

    UNH+2+COPARN:D:00B:UN:SMDG20'

    BGM+126+3+9'

    DTM+137:200907301523:203'

    RFF+BN:SAL/01'

    (...)

This interchange was generated on the 2009/07/30 at 13:23 hrs UTC but the local date/time of issue of the first document is 2009/07/30 at 15:23 hrs. It's reasonable to assume that the sender of the message lives in a GMT+2 time zone. 

COARRI report vs time based COARRI

Basically there are two ways to send COARRI to an EDI customer: 

1. Based a time interval (eg. every 5-minutes); 
2. When all containers have been discharged/loaded from/to vessel. 

The first type of COARRI implies that an unpredictable number of interchanges have been sending to the EDI customer based a time interval. 

The second type of COARRI implies that up to two interchanges (eg. 1 COARRI discharge and 1 COARRI loading) have been sending to the EDI customer. 

Both the ways are valid but I manly use the first one for the following reasons: 

1. To be updated, in (almost) real time, about vessel status is indeed big advantage; 
2. In case containers discharged from vessel are going to be released before the end of vessel operations the EDI customer will still receive first the COARRI and then the CODECO; 
3. Often, receiving COARRI in duly time allows EDI customer to cater the corresponding EDI (eg. COREOR) and speed-up Terminal operations without accumulating too many EDI to be processed at the very last minute.

Digital signature with INVOIC file

Following to my previous post about digital signature, I have gathered further information.

In Italy digital signature is mainly used with INVOIC files. 

A new friend, Mr. Matteo Maiorano employed at Derwid srl, sent me a very interesting sample: I have post it in the forum for your findings. 

Digital signature

Time ago I received, from an EDI customer, an Interchange proposal concerning COREOR messages with a digital signature.

In the beginning it seemed to me a very good idea: the delivering of import containers is a rather delicate matter and a digital signature can: 

• Prove that EDI message is created from a known sender; 
• EDI message is not altered in transit.

Unfortunately, when I saw the sample COREOR  I could not believe my eyes; message looked, more or less, like this: 

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1

UNB+UNOA:3+XXXX:ZZ+ITSALSCT:ZZ+120902:1055+3733'

(...)

UNZ+1+3733'

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAk5gmeYACgkQ3lkq35eQ2s+iowCggEuSTpVW5cxbpz+W9gnVCzU0

UxcAn3t2ZRUCkKIH/ElN/UmVAz0po21d

=aSjJ

-----END PGP SIGNATURE-----

For sure digital signature could be verified manually by means of an external program before processing the message but, at least in my very modest opinion, this was not the way to implement digital signature in an EDI protocol.

I spent some time to found out a consistent documentation and also discussed this issue in a Linkedin's group: I would like to share EANCOM (ie. a subset of UN/EDIFACT) documentation in case you need to handle a similar issue.

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'

Main carriage transport in COPARN

An error that often I have to handle manually in my EDI environment concerns the 'Main Carriage Transport' declared in the H.TDT.TDT segment of some COPARN messages.

Let’s have a look at the following sample:

(...)
TDT+20+2036+1++XXX:172:166+++XXX:103::VESSEL NAME'
LOC+9+ITGOA:139:6:GENOA'
LOC+11+AUMEL:139:6:MELBOURNE'
DTM+133:201209030000:203'
NAD+CF+XXX:172:166'
NAD+MR+ITSALSCT’
EQD+CN++22GP:102:5++2+4'
RFF+SQ:001'
EQN+1'
LOC+163+AUMEL:139:6:MELBOURNE'
MEA+AAE+X+KGM:19250'
TDT+1+TRANSPORTER+3'
LOC+165+ITSAL:139:6:SALERNO'
(...)

That’s a COPARN concerning a container with the following characteristics:

1. To be loaded onto a vessel qualified as 'Main Carriage Transport';
2. Loading port: Genoa (ITGOA);
3. Place/Port of discharge: Melbourne (AUMEL);
4. Place/Port of destination for stowage purposes: Melbourne (AUMEL);
5. Activity Location: Salerno (ITSAL).

So here is the final container route:

1. Collected/Deivered at Salerno port;  
2. Loaded from Salerno to Genoa Port by a feeder vessel;  
3. Transhipped from Genoa to Melbourne Port by the mother vessel declared in the TDT segment.

Of course not always mother vessels, operational on external quays,  are stored into my system and unfortunately affected COPARN messages get rejected due to missing valid vessel call.

Restow in BAPLIE file

Some days ago I received the following complaint from an EDI customer:

"However everytime we receive a departure BAPLIE from your Terminal, where we have performed restows, we always get the restowed units showing as loaded from your port which clashes with the restowed unit."

In the beginning, I thought to have messed up some mapping rules but after having a look at the config file I realised that, at my end, everything was set-up properly. 

Here is the EQD segment group concerning a unit restowed by my Terminal:

(...)

LOC+147+0250208::5'
MEA+WT++KGM:6960'
LOC+9+ITSAL'  >> Place/port of loading
LOC+11+PTLEI' >> Place/port of discharge
LOC+83+PTLEI' >> Place of delivery (by on carriage)
LOC+76+ILHFA' >> Original port of loading
RFF+BM:1'

EQD+CN+ABCD1234567+22G1+++5'
(...)

I guess that customer's EDI translator has some issues in handling OPOL (Original Port of Loading) in conjunction with POL (Port of Loading): of course that's not up to me and, at least once, I was happy to close the support request without changing anything ! 

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 !

Standard Exchange Format (SEF)

A reader asked me further information about SEF files.

The Standard Exchange Format (SEF) is an open-standard, computer readable, text format that contains the schematic information of an  EDI document.  

Basically you can use SEF files for:

• Exchanging information about implementation guidelines with your trading partners;
• Importing directly translation or mapping in your EDI software to ease implementation; 
• Posting information via networks to mailboxes or electronic bulletin boards for mass dissemination of implementation guidelines. 

SEF is an open standard, which allows you to create and distribute your own SEF files without any permission or having to pay any royalty fees.

SEF files are editable either with a text editor or with a free tool, developed by EDIdEv, available here.

Here I have upload a MIG which explains the layout of  a SEF file.

Here you can find a sample of a SEF file.

UNOA character set

When processing an incoming EDIFACT message each software determines the character set to use  from the UNB1 data element. No setting in the trading partner agreement is necessary.

In my EDI environment the most used character set is UNOA.

Here is basic rules for UNOA character set:

• Allowed Characters:

Letters, upper case    A to Z 
Numerals               0 to 9 
Space character
Full stop              . 
Comma                  , 
Hyphen / minus sign    - 
Opening parentheses    ( 
Closing parentheses    ) 
Oblique stroke (slash) / 
Equals sign            = 

• Reserved Characters:

Apostrophe             ' segment terminator 
Plus sign              + segment tag and data element separator 
Colon                  : component data element separator 
Question mark          ? release character *


* ?  immediately preceding one of the characters ‘ + : ? restores their normal meaning. E.g. 
10?+10=20 means 10+10=20. Question mark is represented by ??. 

Call sign and Lloyd's number

One of the most frequent error that I have to handle in my EDI environment, while processing incoming EDI transactions, relates to wrong Call Sign / Lloyd's Number stated into the TDT segment as c222.8213.

Here is some useful sites where you can check about vessels Call Sign, Lloyd's Number and other interesting stuff about ships/boats: 

• Equasis (registration required);
• Marine Traffic;
• Vessel Tracker.

MIG codes legend

When reading a MIG (Message Implementation Guide) you might be disoriented from some strange codes close to the segment description. Let's have a sample:

8077 EQUIPMENT SUPPLIER CODE  C   an..3 

1 Shipper supplied
2 Carrier supplied
5 Third party supplied

What's the meaning of 'C' and 'an..3' ?

I guess that this small legend will fix all your doubts ! :)

Status:   
M= Mandatory
C= Conditional

Size:       

a= alpha character(s)

n= numeric character(s)

an= alphanumeric character(s)

..= size is variable, up to the maximum number indicated

Gross weight in EDI transmissions

Recently an EDI customer reported me an issue related to the weights stated into BAPLIE / COARRI of my production environment. 

I was a little bit surprised in discover a coarse translation error in MEA segment concerning c502.6313 (ie. measurement dimension): I used the qualifier G (ie. weight of goods including packing but excluding the carrier's equipment) in order to report the weight of the goods plus carrier's equipment. 

Checking on the ITIGG guidelines I found out the new qualifier EGW which is used in order to declare the gross weight including carrier's equipment.

Here below how the change affected my EDI transmissions: 

 
Carrier's COPRAR Loading:

(...)

EQD+CN+ABCD1234567+45R1:102:5++2+5'
RFF+BN:ORDER-1' 

TMD+3' 

LOC+9+ITSAL:139:6+:BER:ZZZ:SALERNO CONTAINER TERMINAL'

LOC+11+CAMTR:139:6' 

LOC+7+CATOR:139:6' 

MEA+AAE+T+KGM:4550' 

MEA+AAE+G+KGM:22730' 

TMP+2+012:CEL' 

(...)

Terminal's COARRI Loading: 
(...) 
EQD+CN+ABCD1234567+45R1:102:5++2+5'
RFF+BN:ORDER-1'
TMD+3'
DTM+203:201201221233:203'
LOC+11+CAMTR:139:6'
LOC+7+CATOR::6'
LOC+147+340708::6'
MEA+AAE+T+KGM:4550'
MEA+AAE+EGW+KGM:27280'
TMP+2+12.0:CEL'
(...)

 
Terminal's BAPLIE departure: 
(...)
LOC+147+0340708::5' 
MEA+WT++KGM:27280'
TMP+2+012:CEL'
LOC+6+ITSAL'
LOC+12+CAMTR'
LOC+83+CATOR'
RFF+BM:1'
EQD+CN+ABCD 1234567+45R1+++5'
NAD+CA+XXX:172:20'
(...)

Waterside EDI scenario #1

 I have uploaded here below  a sample of waterside EDI scenario.

What do you think about it ?

VESDEP, general infos

Purpose of the message: To provide information about the closing of a vessel and giving information about the actual containers operation.

Parties involved: it's mainly sent from Stevedore or Terminal Operator to Liner Agent.

Each VESDEP message should contain information only about one means of transport/conveyance.

Updates may be subsequently sent.

Here below a sample of the message:

UNB+UNOA:2+SENDER+RECEIVER+120104:1011+1'
UNH+2+VESDEP:D:95B:UN:ITG12'
BGM+630+3+9'
NAD+CA+XXX:160:ZZZ'
TDT+20+1234+1+13+XXX:172:87+++ABCD:103::VESSEL NAME’
RFF+VON:ABCD1234'
DTM+136:201201040830:203'
QTY+DIS:105'
QTY+LOA:200'
QTY+RES:8'
QTY+SHI:2'
UNT+14+2'
UNZ+1+1'

Here you can find a .sef file (version D.00B).