Pages

Friday, 30 September 2011

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.

Thursday, 8 September 2011

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'

Tuesday, 6 September 2011

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