mopdf.com

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 andhttp://tools.ietf.org/html/rfc1006.The 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 (e.g.to 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