DES150: Electronic Data Interchange (EDI) SpecificationDES150: Electronic Data Interchange(EDI) SpecificationAbstractThis document is part of the Technical Interface Specification (TIS) for Direct Trader Input (DTI) toCHIEF and for Inventory system linking. It defines the EDIFACT message interface to be usedbetween CHIEF and the CSPs. It specifies the formats and application protocol rules for themessages and service segments used in the CHIEF messages.Origin/Author :Len ParkinApproved byJenny Arentsen:Date Approved :06/03/2012StatusApproved:Prepared by:Capgemini UK PLC1 Forge EndWokingGU21 6DBPhone 44 (0)1483 764764Crown copyrightFilename:hmce cl 001351.docVersion: 4.0Page 1 of 24

DES150: Electronic Data Interchange (EDI) SpecificationContents1.Introduction . with other TIS Documents.4Requirement .5Document Structure .5Conventions in the Specification.5Data Format .5Transaction Flows .62.EDI Overview . to EDIFACT .8Overall Architecture.8EDIFACT and an Interactive Service.9Transfers, Phases and Transactions .9The Lower Layers .93.EDI Client Sessions . Session Set Up .10Data Transfer within a Client Session.10Client Session Termination.11Classes of EDI Services.11Character Sets .11Retransmission and Recovery.12Priority.12Progressive Transfer .12Security .12Training .124.Application Messages . Principles .14Business Functions .14Message Types used by CHIEF .15UN Standard Messages .15UKC Bespoke Messages.165.Message Definitions . used in the Message Definitions .17Message Branching Diagrams.17Message Specification Tables .17Crown copyrightFilename:hmce cl 001351.docVersion: 4.0Page 2 of 24

DES150: Electronic Data Interchange (EDI) .2UKCTRL.18Branching Diagram.18Message Specification.19CONTRL .20Branching Diagram.20Message Specification.20Error CUSRES .21Branching Diagram.21Message Specification.216.Glossary and references .226.16.2Glossary.22References.22Appendix A:Document control .24Crown copyrightFilename:hmce cl 001351.docVersion: 4.0Page 3 of 24

DES150: Electronic Data Interchange (EDI) Specification1. Introduction1.1 ScopeThis document is part of the Technical Interface Specification (TIS) for Direct Trader Input (DTI) toCHIEF and for Inventory system linking. It defines the EDIFACT message interface to be usedbetween CHIEF and the CSPs. It specifies the formats and application protocol rules for themessages and service segments used in the CHIEF messages.The scope, contents and structure of the TIS are described in Reference [1]. CHIEF provides twoparallel interfaces for DTI, one screen based for human use and one EDIFACT message based forpackage and system use.This document defines the EDIFACT message interface to be used between CHIEF and the CSPs.Its objective is to act, with the other TIS documents, as the technical component of the ‘InterchangeAgreement’ between HMRC and the Trade for on-line CHIEF Electronic Data Interchange (EDI).The TIS is a definition of the interface between CHIEF and the CSPs, not a definition of theinterface to the end system packages. It is therefore the CSP that is the ‘end system’ with whichCHIEF sets up the transport and overlying session connections.This document identifies the CHIEF message set and its use in message exchanges together withthe use of service messages and service segments. It also defines the application protocol rules forthe service messages and service segments used by CHIEF.The EDI messages supported by the CHIEF applications are specified in other TIS documents (seeReferences [4], [5], [6] and [7]).1.2 Relationship with other TIS DocumentsThis document relates to other TIS documents as follows:a.Overview (see Reference [1]) contains a general introduction to the TIS, the overallarchitecture and the contents of the other TIS documents. This includes some generalbackground material on EDIFACT, and such knowledge is assumed here.b.Session Control (see Reference [2]) specifies the way in which sessions are established forEDI (or HCI) message exchange.c.EDI for Imports (see Reference [4]) gives an overview of the handling of Imports by CHIEFand specifies the EDI message interface.d.EDI for Exports (see Reference [5]) gives an overview of the handling of Exports by CHIEFand specifies the EDI message interface.e.EDI for Consignment and Movement Control (see Reference [6]) provides the EDImessages for Import inventory and Export consolidation of consignments and controllingmovements.f.EDI for Requests and Reports (see Reference [7]) provides the EDI message interface forinformation requests and reports for Imports and Exports, and recommended report layouts.g.Data Element Definitions (see Reference [8]) provides the definitions of the data elementsused in the EDI messages.Crown copyrightFilename:hmce cl 001351.docVersion: 4.0Page 4 of 24

DES150: Electronic Data Interchange (EDI) Specification1.3 RequirementIn business terms the requirement is to enable traders to submit electronic declarations to CHIEFfor all the Import and Export procedures. For frontier declarations the trade require interactiveresponse times whereas for supplementary declarations batched input may be preferred. To meetthis requirement CHIEF provides an interactive EDIFACT message based interface. The CSPs canpass the interactive interface on to traders; they can also provide a batch interface. Customs EDCSsupports a batch interface via email.In addition, the CSPs are provided with an EDIFACT message interface to CHIEF for inventorylinking and the receipt of reports for delivery to the trade.The EDIFACT message interface exists alongside a Human Computer Interface (HCI) (seeReference [3]) supporting interactive screen dialogues, though not all of the transactions arepermitted on both interfaces.1.4 Document StructureThe document is structured as follows:a.Section 2 EDI OVERVIEW gives an overview of EDIFACT as a syntax for Electronic DataInterchange (EDI) and how it is used interactively within the CHIEF architecture.b.Section 3 EDI CLIENT SESSIONS describes the mechanisms for the exchange of EDImessages within a client session.c.Section 4 APPLICATION MESSAGES identifies the EDIFACT messages that are used byCHIEF and the rules for their exchange.d.Section 5 MESSAGE DEFINITIONS defines the messages used by CHIEF which are notdefined in other TIS documents.1.5 Conventions in the Specification1.5.1 Data FormatThe EDIFACT data element formats are specified more rigorously than the standard EDIFACTconventions permit. In particular, the level B character set includes lower case letters but manyalphabetic data elements are restricted to upper case letters only.Data format specification is of the form: character-set . length where:‘.’ is optional and means variable up to the given length . It should be noted that variable lengthfields can be compressed by removing leading and trailing spaces and leading non-significant zerosif numeric.Possible character sets are:N - digits only ie. 0-9.n -numeric ie. 0-9, ‘.’ or ‘,’ for decimal mark, ‘-’ if negative. The length of the field definesthe maximum number of significant digits and excludes the sign and decimal mark ifpermitted for the data element.A - capital letters only.Crown copyrightFilename:hmce cl 001351.docVersion: 4.0Page 5 of 24

DES150: Electronic Data Interchange (EDI) Specificationa -capital letters and special characters, namely:.,-()/' : ?!"%&*; and space(ie. the level B character set except for the lower case letters and the digits 0-9).t -text (ie. the full level B character set).Combinations of these character sets can be specified (e.g. A1N3).It should be noted that ‘a’ and ‘n’ have the same definition as used in EDIFACT elementspecifications when the character set is level A. The additional CHIEF character sets can bemapped onto the EDIFACT definitions as follows:N n or an;A a or an;t an.The CHIEF length specifications must be compatible with the EDIFACT element definitions:a.EDIFACT Variable Length. The CHIEF specification can be shorter and variable or fixed. Iffixed, the values permitted by CHIEF must not be compressible by EDIFACT rules, eg. noleading zeros if EDIFACT ‘n’.b.EDIFACT Fixed Length. The CHIEF specification must be of the same fixed length.1.5.2 Transaction Flows(Sub-)transaction flows are depicted thus:End UserInventory SystemCHIEFREQUEST-- -- ------------------------- ---o-- ------ A single phase Transactionconsisting of a requestaction 1 action 2followed by a response within a few (say 3) seconds. RESPONSE A- ------------------------- -- RESPONSE B- ------------------------- ---------- --- A subsequent transactionspawned from the previoustransaction for immediateprocessing (ie. occurringwithin a few seconds ofthe completion of theprevious transaction). flow to thesubsequenttransactiontriggered by theprevious oneFurther subsequenttransactions as required.Crown copyrightFilename:hmce cl 001351.docVersion: 4.0Page 6 of 24

DES150: Electronic Data Interchange (EDI) SpecificationThe following conventions are used in the flow diagrams:-- --,-- --Horizontal flow with direction indicated by arrows. or Vertical flow from top to bottom except where indicated.- - - -Broken flow need not be via an Inventory system (eg. CIE).[]Optional data/action.{}Only fields that differ from those in the request are returned in theresponse.- --? Condition The flow continues beyond the condition if the condition is true.- --o- Choice of flow (one of the paths is taken as determined by a conditionannotated on the path).(xref)Choice of previous/subsequent sub-dialogues.(a)Link to a subsequent transaction within a sub-dialogue.The handling of errors is not shown either for failures of protocol or syntax or for data validationerrors (e.g. invalid consignment/entry reference). Such errors will be notified by means of aCONTRL or UKCTRL response.End of section 1Crown copyrightFilename:hmce cl 001351.docVersion: 4.0Page 7 of 24

DES150: Electronic Data Interchange (EDI) Specification2. EDI OverviewThis section gives an overview of EDIFACT as a syntax for Electronic Data Interchange (EDI) andhow it is used interactively within the CHIEF architecture.2.1 Introduction to EDIFACTWhile EDIFACT itself is a syntax definition, its messages can only be exchanged within an actual ITenvironment. The physical network, the application structure and the supporting system softwaretogether define the environment in which EDIFACT messages can be generated, exchanged andanalysed. This section describes the principles, the next the implementation aspects.An ‘EDIFACT processor’ can be considered as itself consisting of three layers:a.An upper layer interfacing with the true application.b.A central layer concerned with message construction and analysis.c.A lower layer concerned with protocol control.ApplicationEDIFACT Processor(No knowledge of data envelope)Application Program Interface (API)EDIFACT message construction and analysisEDIFACT protocol handlingSession ServiceNetwork(No knowledge of data contents)This section looks at the lower protocol layer. This is the application-to-application dialogue.Section 4 outlines the upper layer – the message set. The central layer, the processor itself, is anessentially mechanical process which is, once message contents and protocol are defined,transparent to this external interface definition. Note that once some general guidelines areestablished – such as agreeing the message set – progress on protocol and contents can proceedlargely independently2.2 Overall ArchitectureIn the CHIEF architecture, the provider of a processing function is termed the server and the user istermed the client. It is the client that initiates the connection and the overlying client session (seeSection 3.1) in order to access a service. On the CHIEF/CSP interface the servers for Import/Export declarations are on CHIEF and the servers for report delivery are provided by the CSPs.As described in Reference [1], CHIEF offers two complementary services to the Trade:a.EDI messaging – designed for machine users, device independent and EDIFACT encoded.This is defined in this document.b.The Human Computer Interface (HCI) – designed for human users, device dependent andICAB-02 encoded. This is used for screen-based entries and enquiries and is described inReference [3].Crown copyrightFilename:hmce cl 001351.docVersion: 4.0Page 8 of 24

DES150: Electronic Data Interchange (EDI) SpecificationThese two services are supported by a common transport service. On CHIEF the data is alsopresented to the application in the same way so that, for the bulk of processing, the application isunaware whether it is processing an EDI or HCI transaction.2.3 EDIFACT and an Interactive ServiceCHIEF offers an interactive EDIFACT service where an on-line connection is maintained betweenCHIEF and the CSP for the duration of a client session. As such it utilises the same underlyinginterfaces (and works in a similar software environment) as the HCI.The CHIEF specification uses standard EDIFACT messages exchanged within a client session (seeSection 3). There is no requirement to batch messages for transfer within a client session. Theequivalent information to that contained in the interchange segments (UNB, UNZ) for identifying thesource (client) and destination (server) is established with the client session.There are no consequent changes at the user segment or element/code list level, the same UNSM(UN Standard Message) (e.g. generated in a standard EDIFACT environment by a package) can berelayed onto the CHIEF Interactive EDIFACT service simply by extracting it from its enclosinginterchange segments.2.4 Transfers, Phases and TransactionsOnce a client session as defined above has been set up then transfers can take place. In the caseof the CHIEF interactive service there is only one message in the transfer.The CHIEF strategy for transfer acknowledgement is described in Section 3. An enquiry and theresponse is called a phase (or message-pair). A phase implies acknowledgement at the applicationlevel – not the acknowledgement in a lower layer (e.g. transport). Thus on CHIEF each messagehas its own defined rules for transmission and acknowledgement.A sequence of phases complete a transaction – the unit of application defined work which in its finalphase results in a set of consistent changes in the database. In general, EDI transactions aredefined to be single phase, for example, the input of a CUSDEC message and the output of thesubsequent CUSRES response – human interaction is normally required before a transaction needbe multi-phase. A sequence of transactions may be required to complete a business function, forexample, the clearance of an inventory linked import entry (see Section 4.2).2.5 The Lower LayersThe CHIEF/CSP interface is ISO Transport Services RFC 1006 over TCP /IP. TCP port 102 mustbe used. See the relevant Interchange Agreement between CHIEF and each end system and ISO/CCITT higher level layers (OSI session, presentation, and application) continueunchanged without knowledge of the fact that they are running on a TCP/IP network.End of section 2Crown copyrightFilename:hmce cl 001351.docVersion: 4.0Page 9 of 24

DES150: Electronic Data Interchange (EDI) Specification3. EDI Client SessionsThis section describes the mechanisms for the exchange of EDIFACT messages within a clientsession.3.1 Client Session Set UpThe CHIEF session service is defined in Reference [2]. How it is used by the EDI interface issummarised below. The session initiator is termed the client, the provider of the service to which itconnects is termed the server. The CHIEF/CSP interface is symmetrical – which end is the serverdepends on the type of service (see Section 3.4).For an end-user session, the client system is responsible for authenticating the user beforeestablishing a session with the required service. The start session request contains the informationthat the server requires to authorize access to the system and to establish the required operatingclearance.3.2 Data Transfer within a Client SessionWithin the client session, data is transferred in the form of EDIFACT messages. A transfer consistsof a single EDIFACT message. The transaction definition specifies the EDIFACT message type tobe used for each enquiry and response message. If any errors are detected in an enquiry messagethe server returns an error response message. If any error is detected by the client in a responsemessage it is treated as a system failure – logging diagnostic information for investigation andaborting the client session.EDIFACT service segments (shown below) are used to define each message. UNH and UNT areused to frame each message transmitted within the session. UNS is used to separate sections of amessage.When the message is being sent to a server for onward delivery (e.g. a report to a CSP), themessage is further enclosed within UNB and UNZ segments with the destination for final deliveryidentified in the UNB segment.SegmentTitleCHIEF UseUNBInterchange HeaderIdentifies the destination for onward delivery of the enclosedmessage. Not used in client sessions with end-users.UNHMessage HeaderIdentifies the type of message that follows.UNSSection ControlSections are required in message definitions where thesame segment can occur in different places within themessage definition (e.g. NAD in CUSDEC).UNTMessage TrailerRequired by the syntax rules to mark the end of the messagethat started with a UNH.UNZInterchange TrailerRequired by the syntax rules to mark the end of theinterchange that started with a UNB.The CHIEF use of the service segments is specified in the message definitions in Section 5 andReferences [4], [5], [6] and [7].Crown copyrightFilename:hmce cl 001351.docVersion: 4.0Page 10 of 24

DES150: Electronic Data Interchange (EDI) SpecificationIt should be noted that CHIEF does not make use of the MESSAGE REFERENCE NUMBER in theUNH and UNT segments – within the context of a client session the reference is not required.However, the reference in the UNT is checked against that in the corresponding UNH and thereference is returned in the CONTRL or UKCTRL message when it is used as the response.Note that within an interactive EDI client session, CHIEF regards receipt of unexpected servicesegment (e.g. UNB or UNZ within an end-user session) as a protocol violation.3.3 Client Session TerminationNormal termination involves the client sending an End Session command. The client must howeverallow for receiving a Forced End from the server at any time and the client can Abort at any time.The commands are defined in Reference [2].3.4 Classes of EDI ServicesReference [2] identifies a number of services that are provided by CHIEF and the CSPs for EDItransactions. These services together with the client session concurrency that each can support isdefined in the Interchange Agreements.These services can be classified as follows:a.Services supporting interactive transactions from end-users (or packages/systems working ontheir behalf), e.g. traders entering CUSDEC based declarations to CHIEF.b.Services supporting the onward delivery to end-users of unsolicited reports/broadcastsgenerated by another system, e.g. broadcasts and reports originating in CHIEF for delivery totraders by a CSP.c.Services supporting inter-system transactions, e.g. the service provided by CHIEF to supportinventory messages such as the goods arrival notification derived from a berthing.3.5 Character SetsThe character set used is defined by the application and is assumed to be carried transparently bythe lower layers. According to the standard (see Reference [12]) this can be either by privateagreement or by use of EDIFACT options. EDIFACT offers ‘Level A’ (no lowercase) or ‘Level B’(ISO 646 subset) options and a UNA ‘Service String Advice’ segment to specify non-standardseparators. The CHIEF character set and its use is given below.a.The UNA Service Advice segment is not used.b.The level B character set is a subset of ISO 646. This permits use of the upper and lowercase alphabetic characters, the numerals 0 to 9, the space character and the following specialcharacters:.,-()/' : ?!"%&*; In addition, the characters below have the associated functions:NameCharactercodeUseIS 41/12Segment terminatorIS 31/13Data element separatorIS 11/15Component data element separatorCrown copyrightFilename:hmce cl 001351.docVersion: 4.0Page 11 of 24

DES150: Electronic Data Interchange (EDI) Specification3.6 Retransmission and RecoveryThe underlying protocols used by CHIEF ensure that messages passed to the session layer areeither delivered or the session connection is aborted. There is no requirement for the application toretransmit messages within a client session.The application in the client is responsible for recovery when the underlying session aborts or theclient application fails. Such failures can occur when the client is unsure whether a transaction hascompleted in the server system (committing data to its database) or not.The client application is responsible for recovery, repeating the transaction as required.transaction can be repeated in a restarted client session or in a different client session.TheIt is recommended that the client application uses DECLN-UCR (mandatory for SupplementaryDeclarations), since that enables CHIEF to detect a repeated transaction and respond with a repeatCUSRES thereby avoiding the creation of duplicate entries.3.7 PriorityAlthough there is a business case for more than one class of service offering different turn-roundtimes (e.g. Supplementary declarations are less critical than the transactions involved in clearinggoods at the frontier), all CHIEF EDI and HCI traffic runs at the same priority in the same TPservice. Though EDIFACT offers a Processing Priority Code at the interchange level CHIEF uses asingle priority message service (and no use of ‘expedited data’).3.8 Progressive TransferThe Syntax Implementation Guidelines (Reference [11]) allows successive transmissions to beused to upgrade or amend the previously transmitted data or to add new items.Such transfers are not used on CHIEF, which requires a complete entry retransmission foramendment.3.9 SecurityInteractive EDI transactions occur within a client session. The same access security checks applyfor EDI and HCI client sessions.The method of connection at the transport level and below ensures that any possible misdirectioncan be ignored at the application level. Any security requirements must be taken into account inagreeing the physical interface between CHIEF and the CSPs. This interface is detailed in theInterchange Agreement between CHIEF and each end system as specified by HMRC.3.10 TrainingAs defined in Reference [2], a client session is established for a purpose which is either operationalor training. Within a training client session, training data can be created and maintained, withtraining data displayed in preference to operational data. CHIEF does not allow any access totraining data within an operational client session.Since the forwarding of reports for onward delivery involves updating queues within CHIEF, onlytraining data can be forwarded within a training client session and only operational data within anoperational client session.Crown copyrightFilename:hmce cl 001351.docVersion: 4.0Page 12 of 24

DES150: Electronic Data Interchange (EDI) SpecificationA server is required to handle data according to the rules for the purpose of the client session ( ensure that training output is clearly marked as a TRAINING SPECIMEN). As well as onlyforwarding training data for onward delivery within a training client session, CHIEF also sets the testindicator in the UNB segment.Any resulting secondary actions, such as automatic clearance, will also run in the specifiedpurpose.End of section 3Crown copyrightFilename:hmce cl 001351.docVersion: 4.0Page 13 of 24

DES150: Electronic Data Interchange (EDI) Specification4. Application MessagesSections 2 and 3 examined how messages are exchanged – this section identifies the EDIFACTmessages that are used by CHIEF to exchange information.4.1 Design Principlesa.The reference versions of the EDIFACT standard and its supporting directories used are thoseratified and published by the United Nations in September 1991 (Directory 912), January 2000(Directory 00A) and May 2004 (Directory 04A).b.All messages with UNSM names are defined as proper subsets of the UNSM definitions (seeReference [9]).c.All CHIEF bespoke messages are defined using standard segments (see Reference [9]) andcomply with the EDIFACT Syntax Implementation Guidelines (see Reference [11]) and relateddocumentation.d.In many cases CHIEF data item definitions are more constrained than the data element, asdefined in Reference [9], onto which they are mapped in terms of their maximum length andthe permitted character sets. The dat

DES150: Electronic Data Interchange (EDI) Specification Crown copyright Filename:hmce_cl_001351.doc Page 8 of 24 Version: 4.0 2. EDI Overview This section gives an overview of EDIFACT as a syntax for Electronic Data Interchange (EDI) and how it is used interactively within the CHIEF a