Merry Christmas !!!

In the past I never took care about such stuff: maybe I'm getting old or maybe not...
Anyway, best wishes to everybody who's following me here !

CALINF, general infos

Purpose of the message: To provide information about the planned arrival of a vessel (ie. E.T.A.) and the expected container operations.

Parties involved: It's mainly sent by Liner Agent to Terminal.

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

Updates may be subsequently sent.

Here below a sample based on D99B.

UNB+UNOA:2+SENDER+RECEIVER+030627:1224+000000281++CALINF+++XXX'
UNH+000000385+CALINF:D:99B:UN'
BGM+96+000000385+9'
DTM+137:200306271224:203'
NAD+MS+XXX:172:166'
TDT+20+023N+1++XXX:172:166:NIPPON YUSEN KAISHA+++3FVSB:103::IRIS'
LOC+5+ARBUE:139:6'
DTM+136:200306040600:203'
LOC+153+BRRIG:139:6'
DTM+132:200306060600:203'
LOC+153+BRPNG:139:6'
DTM+132:200306070600:203'
LOC+153+BRRIO:139:6'
DTM+132:200306090600:203'
LOC+153+BRSSZ:139:6'
DTM+132:200306100600:203'
LOC+153+ZADUR:139:6'
DTM+132:200306250600:203'
LOC+153+SGSIN:139:6'
DTM+132:200307080600:203'
LOC+153+HKHKG:139:6'
DTM+132:200307120600:203'
LOC+153+JPNGO:139:6'
DTM+132:200307190600:203'
LOC+153+JPYOK:139:6'
DTM+132:200307250600:203'
UNT+26+000000385'
UNZ+1+000000281'

Container messages set

Most of the messages handled till now belong to the container messages set (ie. CO**** ).

Here below the full set of container messages:

CALINF Call information ( vessel ) / advice of expected container operations 
COARRI Container discharge / loading report 
CODECO Container gate in gate out report 
CODENO Document expiration / clearance ready notice 
COEDOR Container stock report 
COHAOR Container special handling order 
COPARN Container announcement 
COPINO Container pre notification 
COPRAR Container discharge / loading order 
COREOR Container release order 
COSTCO Container stuffing / stripping confirmation 
COSTOR Container stuffing / stripping order 
DESTIM Equipment damage /  repair estimate 
VESDEP Vessel departure

Here, under the label  miscellaneous document, you can find a very interesting document by the ITIGG. This document is referred to in the formal message documentation of all the CO**** messages as the "Guide to the Scenario of EDIFACT Container Messages".

In the next post I'll handle the remaining messages of the set.

APERAK request

The use of the APERAK, of course, must be agreed between EDI partners.

Anyway an EDI partner can ask for an acknowledgement, relating the receipt of the message sent, by means of data element 4343 on the BGM segment level.

Here below the sample of a BGM segment in a COREOR message requiring for an APERAK:

(...)
BGM+12:::TRANSPORT CARGO RELEASE ORDER+1234+9+AB'
RFF+REO:ORDER-ID'
(...)

The qualifier AB stands for Message Acknowledgement and indicates that an acknowledgement relating to receipt of message is required.

Using APERAK to confirm a truck appointment

In the previous scenario the Container Terminal, whenever agreed, can respond to the COPINO sent by the Inland Carrier with an APERAK.

The function of this message is: 

1. To inform a message issuer that his message has been received by the addressee's application and has  been rejected due to errors encountered during its processing in the application;
2. To acknowledge to a message issuer the receipt of his message by the addressee's application.

I have drafted an APERAK sample where the following data are available:

1. The reference to the COPINO previously acknowledged;
2. The reference of the truck appointment;
3. Start/End time slot for the truck appointment; 
4. The information related to the specified application error or acknowledgement.

UNB+UNOA:1+SENDER:ZZ+RECEIVER+110908:1130+1'

UNH+2+APERAK:D:96B:UN:ITG13'

BGM+11+3+9+AP'

DTM+137:201109081130:203'

DTM+64:201109091000:203'

DTM+63:201109091200:203'

RFF+ACW:00000001'

ERC+OK'

RFF+AEL:APPOINTMENT-ID'

FTX+AAO+++APPOINTMENT NR ?:APPOINTMENT-ID'

UNT+10+2'

UNZ+1+1'

Export scenario

I have prepared an export scenario based on the new EDI transactions we have discussed in the last posts.

A couple of remarks: 

1. The arrangement of the transportation between Liner Agent and Trucking Company is not included yet; 
2. It's supposed to use the pre-advise only for full export containers;
3. With the term 'CFS' (Container Freight Station) we refer to the factory where containers are going to be stuffed. 

Of course that's not the only way to cover such a scenario so if you have different proposals then let me know ! 

Talking about XML and benefits of using XSD

Some days ago I was contacted from a new friend who introduced me to a new EDI service available here.

I would be glad to say a lot of good stuff about ediFabric but I guess it's better post a small explanation/presentation prepared by the developer him self ! :)

At the moment the service is free of charge so have a look and enjoy !

ediFabric is an integration service to seamlessly describe, translate and collaborate EDI.

Our vision is that EDI definitions and messages can be accurately described using mature and well known format such as XSD.

XSD is used to express a set of rules to which an XML document must conform in order to be considered 'valid' according to that schema.

The apparent benefits of tallying EDI definition and XSD are:

1. Ability to describe EDI definitions using a powerful meta-language, supporting both complex structure and data models.
2. XSD is easy to get into – being one of the major formats used widely to define interfaces, you could easily find any information, samples or tutorials required on the internet.
3. Virtually every software solution or system in the world, which adheres to the latest best practice principles and exposes well defined interfaces, is likely to be naturally XSD friendly. This gives you immediate access to countless number of systems to integrate with.

Having a flexible way to describe EDI definitions is only a part of all features. Adding to the above a flexible parser to convey the conversions is even more impressive.

Parsing from EDI to XML is not a straightforward process. What would be the point of having a static translator, which produces an output you cannot control?

What ediFabric introduces is the concept of a ‘partner’. The partner serves as a separate configuration or instruction set to the underlying parser engine. When you translate an EDI message to XML, the parser engine will check the partner for the following:

- The EDI definition (described with XSD)
- The interchange settings (separator sets, target namespaces, encoding)

The ‘partner’ will influence how the parser translates the same EDI definition. The benefit of this is that you are in complete control of both the EDI definition and the parsing process.

You could for example, have an Edifact INVOIC, parsed in two different ways (either by structure or separator sets) for two different receiver\sender parties. All of that driven by configuration.

ediFabric gives you the tooling to describe and translate EDI messages in a controllable and interface-friendly approach, making communication with other systems easy to establish and support.

It’s hosted in the cloud (currently in Microsoft Azure), and thus offering 99.99% up time as well as it’s scalable enough to handle any increase in load or throughput.

The parsing functionality will be exposed as a web service API’s, to be consumed form various systems or directly from code.

The configuration functionality is available as a web portal at www.edifabric.com, where you can use one of our hundreds EDI definitions (the currently supported formats are Edifact and X12) or construct your own and upload them to your repository. A validation page is provided, where all translations can be quickly tested.

In ediFabric we are determined to deliver a best of breed solution and evolve quickly to meet all our customers’ demands. We will be delighted if you could have a look around and confirm that we have met your expectations.

www.edifabric.com

COSTOR, general infos

Purpose of the message: The COSTOR message is intended to provide a packing or unpacking facility with details of cargo items to be  stuffed (ie. packed) into specified shipping containers, or stripped (ie. unpacked) from specified containers.

Parties involved: The COSTOR is mainly sent from Carrier/Liner Agent to Container Freight Station (ie. stuffing / stripping location).

In my EDI environment COSTOR is not used at all; in case of stuffing/stripping moves CODECO is normally used: a specific post about this topic will be issued later.

I have drafted a COSTOR sample based on the ITIGG MIG vers. 1.2. Here below you can find an extract: the full sample will be posted and commented subsequently on the forum in the UN/EDIFACT Sample section.

(...)
EQD+CN+ABCD1234567+2210:102:5++3+5'
RFF+SQ:1'
EQN+1'
DTM+UST:20110730:102'
LOC+11+ITAVE:162:6'
GID+1+785:CT:::CARTON(S)'
HAN+61:130:184:FOR UNPACKING/UNSTUFFING'
FTX+AAA+++FOODSTUFFS, NOS'
DTM+GPE:20110729:102'
MEA+AAE+G+KG:23000'
PCI++MARKS AND NUMBERS:LOT NO.1-6'
SGP+ABCD1234567+785'
MEA+AAE+G+KG:23000'
(...)

BAPLIE and 11-tiers on deck

Life goes on and Shipping Lines are going to maximize their profit by using vessels bigger then ever.

Vessels with up to 11-tiers on deck may create some issue with the BAPLIE file: according the ISO recommended numbering the tier on deck should start from 82; this would mean that in case of 10th or 11th tier the corresponding ISO format should be 100 or 110.

Unfortunately, in the current cell position format, the tier number cannot exceeds the two digits; this brings me to the next question: how are you handling this issue in your working environment ?

It was told me that, in order to overcome this issue, some Carriers decided to start the tier numbers on deck not with 82 but with 62 but what about you ?!

How to get an INVOIC from a csv file

Surfing the web I found out a very interesting project here.

At the moment the developer has only implemented the conversion of a *.csv file in INVOIC D96A but also let me know that, in case of request, can implement any new UN/EDIFACT format based on a concrete sample / MIG. 

You can download a sample of *.csv file here: check for the file structure (the column names are included in the first line), generate your own file with your own data and submit it via the ftp: you'll get a fully structured INVOIC D96A for free !

Here you can find all the details and here a sample of INVOIC generated via this process.

Have fun guys !

Added Sub-Forums "UN/EDIFACT Samples" on My EDI Notes Forum

In my modest opinion samples are as important as a good UN/EDIFACT guide.

That's because I decided to add to the forum a section entirely dedicated to UN/EDIFACT samples.

Fell free to post your samples and open all the topics you wish !

Transhipment Scenario

Here below a new scenario concerning the transhipment of containers from Feeder Vessel to Deep Sea Vessel.

COPINO case of study: ECT Terminal

The below snapshot comes from ECT web site and offers a very interesting overview about the procedures currently implemented to deliver import containers by means of UN/EDIFACT messages COREOR and COPINO.

Parties involved in the procedure are:

- Box Operator (ie. Line, Liner Agent etc) which is in charge for COREOR;

- Inland Carrier (ie. Trucking Company or Barge) which is in charge for COPINO.

Basically containers will be released from the Terminal only in case the PIN number declared by Inland Carrier in COPINO will match with PIN number declared in COREOR by Box Operator.

Look here about how to declare a PIN number into COREOR.

Poll, UN/EDIFACT messages implemented

UN/EDIFACT Message Structure

A couple of days ago a friend of mine asked for some help in order to work on a thesis about UN/EDIFACT messages.

I have prepared some charts and I would like to share the following one. 

For further infos about this item you can also have a look here.

COPINO, container status

During the 51st SMDG Meeting at La Spezia it was discussed to use the COPINO to retrieve the container status at the terminal. Here is related scenario: 

1. Rail Operator sends pick-up notification to the terminal before container is discharged from a vessel;
2. Terminal Operator replies with acknowledgement message: container unknown / not in terminal;
3. Line Operator sends discharge COPRAR to terminal: since now to go on equipment is known; 
4. Line Operator sends COREOR to terminal: since now to go on equipment can be released;
5. Rail Operator sends pick-up notification to the terminal before container is discharged;  COPINO is processed: container is known but not yet at the terminal;
6. Terminal Operator discharges container;
7. Rail Operator sends pick-up notification to the terminal: COPINO is accepted without any errors.

If you want to gather more infos, check here under the directory Meetings -> Minutes Archive: there is a very interesting presentation by ECT terminal.

COPINO, general infos

Purpose of the message: COPINO is used to notify that an inland carrier will deliver or pick up a container.

Parties involved: COPINO is mainly sent from Liner Agent or Trucking Company to Terminal Operator.

I have to admit that in my EDI environment COPINO is not used at all: for some circumstances we are not confident with appointments & container pre-notifications. Anyway, in Northern of Europe, several Terminal Operator implemented successfully this message: PSA Antwerp is a good "case of study".

Based on the documentation that I gathered on the web PSA Antwerp implemented COPINO with barges: "The COPINO message is sent by the barge operator to the container terminal operator. It contains a list of all the full and empty containers to be loaded on barge." Here are some samples from their MIG:

 Example of a COPINO load order for 1 full import container
UNB+UNOA:2+WCT+PSAHNN+081001:1809+WCT0810011809'
UNH+WCT13+COPINO:D:95B:UN:ITG13'
BGM+661+1208440E1+9'
RFF+XXX:1'
TDT+1+2402+8++WTM:172:20+++1234567:146::COPINO TESTLICHTER'
LOC+88+BEANR:139:6+BEANR1742:TER:ZZZ'
DTM+132:200810010600:203'
NAD+MS+WTM'
NAD+MR+PSAHNN'
GID+1'
FTX+AAA+++KANE ACE PA610 SB'
MEA+AAE+G+KGM:19540'
SGP+TEST1111111’
EQD+CN+TEST1111111+2210:102:5++3+5'
MEA+AAE+G+KGM:23540'
TDT+20++1’
LOC+7+BEMEH:139:6+00ECM:139:6’
CNT+16:1'
UNT+18+WCT13'
UNZ+1+WCT0810011809'

 Example of a COPINO load order for 1 full export container
UNB+UNOA:2+WCT+PSAHNN+081001:1809+WCT0810011809'
UNH+WCT13+COPINO:D:95B:UN:ITG13'
BGM+661+1208440E1+9'
RFF+XXX:1'
TDT+1+8536+8++WTM+++1234567:146::COPINO TESTLICHTER'
LOC+88+BEANR:139:6+BEANR913:TER:ZZZ'
DTM+132:200810010600:203'
NAD+MS+WTM'
NAD+MR+PSAHNN'
GID+1'
FTX+AAA+++KANE ACE PA610 SB'
MEA+AAE+G+KGM:19540'
SGP+TEST2222222'
EQD+CN+TEST2222222+2210++2+5'
MEA+AAE+G+KGM:23540'
TDT+20++1++MSC:172:20+++11111:103::TESTW'
LOC+7+NLRTM:139:6+00ECM:139:6’
CNT+16:1'
UNT+18+WCT13'
UNZ+1+WCT0810011809'

Off course the means of transport "barge" can be replaced with any other inland carrier type such as: truck, rail, etc.

Import scenario #2

A new import scenario based on the messages we have handled till now.

EDI directory

CODECO, pre-carriage info

Here is the definition of "pre-carriage" based on ITIGG documentation: "physical movement of a container before arrival at a place/port for loading on the primary means of transport."

In the below sample of EQD.TDT segment group you can find detailed infos (ie. Trucking Company-id, Truck Plate) related to the pre-carriage of a Full-In container:

(...) 

TDT+1++3+31+GKP0001:172+++NA098WY:146:ZZZ'
LOC+7+ITSAL:139:6+SCT:TER:ZZZ'
(...)

CODECO, goods info

Normally cargo details should been given by messages belonging to IFTM-set but, where agreed by users, CODECO can also provide brief cargo details.

Here below a sample:

(...)

GID+1+785:CT:::CARTON(S)'
FTX+AAA+++VARIOUS, NOS'
MEA+AAE+G+KGM:21080'
MEA+AAE+T+KGM:2200'
(...)

I have used Package Code List based on JMA/ITIGG/121/v.11 that you can find here under the directory Documents / Downloads.

CODECO, general infos

Purpose of the message: CODECO is used to confirm that a container was delivered or picked up by an inland carrier (ie. road, rail or barge). Message is also used to report:

• In/Out moves from/to the Repair Location; 
• Change of the lease status of the container in Leasing Industry (ie. on/off hire transactions). 

Parties involved: CODECO in mainly sent by Terminal Operator to Carrier / Liner Agent.

Here below a sample of CODECO concerning the report of a Full-In move by Terminal Operator.

UNB+UNOA:2+SENDER-ID+RECEIVER-ID+110117:1401+1292528559464'
UNH+1292528559355+CODECO:D:95B:UN:ITG14'
BGM+34:::TRANSPORT EQUIPMENT GATE IN REPORT+07470574000001+9'
TDT+20+00018N+1+13+GEK:172:87+++47AVS:103::SALERNO PRIDE'
LOC+9+ITSAL:139:6+SCT:TER:ZZZ'
DTM+132:201101241000:203'
NAD+CF+GEK:172:87'
NAD+AG+LINER AGENT:160'
GID+1'
FTX+AAA+++VARIOUS, NOS'
EQD+CN+GEKU1234567+22G1:102:5++2+5'
RFF+BN:SAL/01'
DTM+7:201101171359:203'
LOC+11+CAMTR:139:6'
LOC+165+ITSAL::6+SCT:TER:ZZZ'
MEA+AAE+G+KGM:21080'
MEA+AAE+T+KGM:2000'
SEL+A154+CA'
SEL+133726+SH'
FTX+DAR++6:ZZZ:184+NOT DAMAGED'
TDT+1++3+31+XXX0001:172+++XX098WY:146:ZZZ'
LOC+7+ITSAL:139:6+SCT:TER:ZZZ'
CNT+16:1'
UNT+23+1292528559355'
UNZ+1+1292528559464'