Tuesday, 6 September 2011

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

Saturday, 23 July 2011

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'
(...)

Tuesday, 19 July 2011

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 ?!

Friday, 15 July 2011

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 !

Thursday, 14 July 2011

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 !

Wednesday, 13 July 2011

Transhipment Scenario

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

Monday, 11 July 2011

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.